Re: git: d8a3e1d47a90 - main - www/firefox: update to 117.0 (rc1)

Tomoaki AOKI wrote on 2023/08/30 21:40:
> On Tue, 29 Aug 2023 09:06:46 +0900
> Tatsuki Makino <tatsuki_makino@hotmail.com> wrote:
>> So, it is better to put it on lldb.
>> For example,
>> lldb -o r -- /usr/local/bin/firefox --ProfileManager --no-remote --private-window
>
> Thanks for advice!
> Uploaded backtrace to Bug 273291.
> 

Thank you. And sorry, that may not be enough.

We all don't need to worry about ProfileManager, no-remote and private-window because they are for my experimentation, choosing profiles, launching multiple processes at the same time, and keeping the profiles as clean as possible :)

And here are some reasons why I think this core is still not enough.
That is not limited to firefox, so I will write to the mailing list :)

>> lldb -o r -- /usr/local/bin/firefox
The reason we want the program to run on lldb like this is because firefox has a feature to generate crash reports.
Cores created by such programs may have stopped at the same time the crash report was created.
If we are running it on the debugger, it will stop when the problem first occurs, so it will be in the correct position.
This was encountered with multimedia/{lib,}openshot.

One of the reasons I want you to recreate the backtrace one more time is that firefox is a multi-threaded program.
I don't have an understanding on this and would like someone with more knowledge to take over explaining it, but I think it is a compatibility issue between signal and multithreading.
It seems that the backtrace of the current thread obtained by bt may not be the backtrace of the thread that caused the problem.
We need to see all the backtraces by "bt all".
I also reflexively paste only the backtrace by bt, but I think it happened before with www/chromium that the backtrace by bt I pasted did not contain anything :)

I'm not a particularly knowledgeable person, but I have had such first-hand experience, and I hope the story can be used as a shortcut for others :)

Regards.