Re: firefox-104.0,2 crashing
- Reply: void : "Re: firefox-104.0,2 crashing"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 19 Aug 2022 17:38:26 UTC
Nice. That looks informative. My knowledge about the internals of Firefox end here. You could get the maintainer of Firefox involved. gecko@FreeBSD.org Regards,Ronald Van: Nuno Teixeira <eduardo@freebsd.org> Datum: 19 augustus 2022 17:45 Aan: Ronald Klop <ronald-lists@klop.ws> CC: ports@freebsd.org Onderwerp: Re: firefox-104.0,2 crashing > > > > > Hi Ronald, > > > @ main-n257458-ef8b872301c5 > > > % lldb --core firefox.core --file /usr/local/bin/firefox > --- > (lldb) target create "/usr/local/bin/firefox" --core "firefox.core" > Core file '/home/nunotex/firefox.core' (x86_64) was loaded. > (lldb) bt > This version of LLDB has no plugin for the language "assembler". Inspection of frame variables will be limited. > * thread #1, name = 'MainThread', stop reason = signal SIGSEGV > * frame #0: 0x00000fd5915adaca libc.so.7`__sys_thr_kill at thr_kill.S:4 > frame #1: 0x00000fd5915266e4 libc.so.7`__raise(s=11) at raise.c:52:10 > frame #2: 0x00000fd5c5a04232 libxul.so`nsProfileLock::FatalSignalHandler(int, __siginfo*, void*) + 242 > frame #3: 0x00000fd5c63da027 libxul.so`WasmTrapHandler(int, __siginfo*, void*) + 327 > frame #4: 0x00000fd58f9ab92e libthr.so.3`handle_signal(actp=0x00000fd58d9b4a40, sig=11, info=0x00000fd58d9b4e30, ucp=0x00000fd58d9b4ac0) at thr_sig.c:301:3 > frame #5: 0x00000fd58f9aaedf libthr.so.3`thr_sighandler(sig=11, info=0x00000fd58d9b4e30, _ucp=0x00000fd58d9b4ac0) at thr_sig.c:246:2 > frame #6: 0x00000fd58e6882d3 [vdso] > frame #7: 0x00000fd5c25f6440 libxul.so`mozilla::detail::RunnableFunction<mozilla::net::AsyncUrlChannelClassifier::CheckChannel(nsIChannel*, std::__1::function<void ()>&&)::$_0::operator()() const::'lambda'()>::Run() + 2000 > frame #8: 0x00000fd5c219f753 libxul.so`mozilla::RunnableTask::Run() + 19 > frame #9: 0x00000fd5c21885f3 libxul.so`mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) + 1539 > frame #10: 0x00000fd5c21875eb libxul.so`mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) + 43 > frame #11: 0x00000fd5c21a21a8 libxul.so`mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_0>::Run() + 56 > frame #12: 0x00000fd5c2194587 libxul.so`nsThread::ProcessNextEvent(bool, bool*) + 1159 > frame #13: 0x00000fd5c2198a8e libxul.so`NS_ProcessNextEvent(nsIThread*, bool) + 78 > frame #14: 0x00000fd5c26b14c8 libxul.so`mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) + 136 > frame #15: 0x00000fd5c2669698 libxul.so`MessageLoop::Run() + 88 > frame #16: 0x00000fd5c4a9ead9 libxul.so`nsBaseAppShell::Run() + 41 > frame #17: 0x00000fd5c59579a6 libxul.so`nsAppStartup::Run() + 118 > frame #18: 0x00000fd5c5a16cbc libxul.so`XREMain::XRE_mainRun() + 3052 > frame #19: 0x00000fd5c5a17317 libxul.so`XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) + 1127 > frame #20: 0x00000fd5c5a176cc libxul.so`XRE_main(int, char**, mozilla::BootstrapConfig const&) + 172 > frame #21: 0x00000fcd6d3ab032 firefox`main + 1010 > frame #22: 0x00000fcd6d3aa98d firefox`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:73:7 > --- > > > Thanks > > > > Ronald Klop <ronald-lists@klop.ws> escreveu no dia sexta, 19/08/2022 à(s) 10:03: > >> >> Hi, >> >> What I find interesting from this mail thread and all follow up emails is that there is no indication that the original problem has anything to do with the ~/.Xauthority and /etc/hosts solution of the other person. >> >> There can be so many causes of a signal 11. >> >> What Nuru needs to do is run a debugger on the firefox.core file and try to get a stacktrace of the error. >> >> From the top of my head: >> >> $ lldb --core <path-to/firefox.core> --file /usr/local/bin/firefox >> > bt >> >> You might need to recompile firefox with DEBUG option enabled to get any sensible output of the debugger. I don't have a lot of experience debugging firefox. >> >> NB: What version of FreeBSD are you running? Send the output of: uname -a >> >> Regards, >> Ronald. >> >> >> Van: DtxdF <DtxdF@riseup.net> >> Datum: woensdag, 17 augustus 2022 21:39 >> Aan: ports@freebsd.org >> Onderwerp: Re: firefox-104.0,2 crashing >>> >>> Hello, >>> >>> I have had the same problem. The problem is not only with firefox, it is also valid with thunderbird in my experience. >>> >>> I have debugged a bit using truss(1) and identified that the ~/.Xauthority file and /etc/hosts is the problem. Actually, the problem is firefox and thunderbird, but the initiators are them. >>> >>> Check what display-names are displayed with `xauth list`. If you see a display name as an invalid host in /etc/hosts, simply remove it with `xauth remove`. >>> >>> My problem is that I changed the hostname, and it stayed after a firefox upgrade, so I had two entries with an invalid hostname and a valid hostname in .Xauthority. >>> >>> See also /etc/hosts to see if there is an invalid host or check if you do not have any entries where a host (such as your hostname) is missing. >>> >>> El 17 de agosto de 2022 4:55:20 p. m. UTC, Nuno Teixeira <eduardo@freebsd.org> escribió:>>>> >>>> Hello to all, >>>> >>>> Is anyone experience firefox crashes? For a long time that I did not see so many crashes. >>>> It core dumped to firefox.core, can I do something usefull with .core to get an ideia of what is causing it? >>>> >>>> "pid 28063 (firefox), jid 0, uid 1001: exited on signal 11 (core dumped)" >>>> >>>> Cheers, >>>> -- >>>> Nuno Teixeira >>>> FreeBSD Committer (ports) >>> >> > > > > -- > > Nuno Teixeira > FreeBSD Committer (ports) > >