Nice.
That looks informative. My knowledge about the internals of Firefox end here. You could get the maintainer of Firefox involved.
ge...@freebsd.org
Regards,Ronald
Van: Nuno Teixeira <edua...@freebsd.org>
Datum: 19 augustus 2022 17:45
Aan: Ronald Klop <ronald-li...@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-li...@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 <dt...@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 <edua...@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)
