Tomoaki AOKI wrote on 2023/08/30 21:40:
> On Tue, 29 Aug 2023 09:06:46 +0900
> Tatsuki Makino <[email protected]> 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.
