User:Skierpage/Firefox early exit
So Firefox 64-bit latest trunk has sort-of worked for me for months. But, if I quit it and restart, I get an immediate early exit with status 1. No error message (except for a benign? "GLib-WARNING **: g_set_prgname() called multiple times").
To avoid this I have to start with -safe-mode then quit and restart, or have a pending update.
I'm trying to debug this using the -g run switch, but I don't know how to get a gdb "Why the heck is this program exiting" stack trace at the point of exiting.
firefox prints "GLib-WARNING **: g_set_prgname() called multiple times", gdb lets me know four new threads start up, but within seconds all four threads exit and firefox exits.
In #developers, mook_sb suggested that Firefox's
Debugging in gdb
firefox -g starts in gdb.
But what then? How do I tell it to break as it's about to exit?
catch syscall exit_group
I enabled catch syscall (Kubuntu launchpad bug filed) and entered
catch syscall exit_group
Then run gives "Recursive internal problem abort (core dumped
Debugging this core file gives the backtrace
Core was generated by `/home/skierpage/programs/firefox/firefox-bin'.
Program terminated with signal 5, Trace/breakpoint trap.
#0 0x00007ffff7dedfc1 in *__GI__dl_debug_state () at dl-debug.c:77
77 dl-debug.c: No such file or directory.
in dl-debug.c
(gdb) bt
#0 0x00007ffff7dedfc1 in *__GI__dl_debug_state () at dl-debug.c:77
#1 0x00007ffff7de5692 in _dl_map_object_from_fd (name=<value optimized out>, fd=<value optimized out>,
fbp=0x7fffffffd440, realname=<value optimized out>, loader=0x0, l_type=2, mode=-1879048191,
stack_endp=0x7fffffffd788, nsid=0) at dl-load.c:959
#2 0x00007ffff7de73a8 in _dl_map_object (loader=0x0, name=0x7ffff736c84d "libgnomeui-2.so.0",
preloaded=<value optimized out>, type=<value optimized out>, trace_mode=<value optimized out>,
mode=-1879048191, nsid=0) at dl-load.c:2235
#3 0x00007ffff7df1d49 in dl_open_worker (a=<value optimized out>) at dl-open.c:289
#4 0x00007ffff7ded386 in _dl_catch_error (objname=<value optimized out>, errstring=<value optimized out>,
mallocedp=<value optimized out>, operate=<value optimized out>, args=<value optimized out>)
at dl-error.c:178
#5 0x00007ffff7df16c7 in _dl_open (file=0x7ffff736c84d "libgnomeui-2.so.0", mode=-2147483647,
caller_dlopen=0x7ffff58b2dbd, nsid=-2, argc=1, argv=0x7ffff7ffec80, env=0x7fffed029180) at dl-open.c:615
#6 0x00007ffff569af66 in dlopen_doit (a=<value optimized out>) at dlopen.c:67
#7 0x00007ffff7ded386 in _dl_catch_error (objname=<value optimized out>, errstring=<value optimized out>,
mallocedp=<value optimized out>, operate=<value optimized out>, args=<value optimized out>)
at dl-error.c:178
#8 0x00007ffff569b2ac in _dlerror_run (operate=0x7ffff569af00 <dlopen_doit>, args=0x7fffffffdbd0)
at dlerror.c:164
#9 0x00007ffff569aee1 in __dlopen (file=<value optimized out>, mode=<value optimized out>) at dlopen.c:88
#10 0x00007ffff58b2dbd in PR_LoadLibraryWithFlags () from /home/skierpage/programs/firefox/libnspr4.so
#11 0x00007ffff58b2e90 in PR_LoadLibrary () from /home/skierpage/programs/firefox/libnspr4.so
#12 0x00007ffff691f2e5 in ?? () from /home/skierpage/programs/firefox/libxul.so
#13 0x00007ffff691844b in XRE_main () from /home/skierpage/programs/firefox/libxul.so
#14 0x0000000000401bc0 in ?? ()
#15 0x00007ffff2d8babd in __libc_start_main (main=<value optimized out>, argc=<value optimized out>,
ubp_av=<value optimized out>, init=<value optimized out>, fini=<value optimized out>,
rtld_fini=<value optimized out>, stack_end=0x7fffffffe488) at libc-start.c:220
#16 0x00000000004019b9 in ?? ()
#17 0x00007fffffffe488 in ?? ()
#18 0x000000000000001c in ?? ()
#19 0x0000000000000001 in ?? ()
#20 0x00007fffffffe792 in ?? ()
#21 0x0000000000000000 in ?? ()
If the _dl_map_object_from_fd is from libgnomeui-2.so.0 , maybe there's a way to break on load of that and see if that's really the problem.
= test libgnomeui-2.so.0
I tried
break _dl_map_object with commands >echo break in _dl_map_object >print name >continue >end
and also
break _dl_map_object if name="libgnomeui-2.so.0"
then ran with this. Lots of _dl_map_objects, including lots in libgnomeui-2.so.0. Then
Breakpoint 4, _dl_map_object (loader=0x7ffff7fc31e0, name=0x7ffff7fc11f8 "libgnomeui-2.so.0", preloaded=0, type=1, trace_mode=0, mode=0, nsid=0) at dl-load.c:1955 1955 in dl-load.c break in _dl_map_object$171 = 0x7ffff7fc11f8 "libgnomeui-2.so.0" Inconsistency detected by ld.so: dl-version.c: 230: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed!
Program exited with code 0177.
Hmm, was that really in libgnomeui-2.so.0?
I tried setting breakpoints on _dl_check_map_versions and that resulted in, if I recall correctly, a missing function in libc.6.0 error 0177.
So, random crashes and an internal crash if I try to catch syscall exit
Looks like when Firefox goes down the fastload road, it screws up.
Start-up issues
mcsmurf points out
- btw: usually Firefox quits during startup to register components (in extensions) from your profile and then starts up again
- but of course this should happen automatically and is normally not visible to the user
233 * @returns true if the application has rewritten the extensions.ini file 234 * and needs to restart to register components/chrome etc, 235 * false otherwise
- safe-mode does not remove the extensions.ini file so I'm not sure if safe-mode might do registering so that is already done for next startup
- skierpage: and when you launch in normal mode (so not safe-mode) the extensions.ini file gets deleted
anyway, gotta go, if you want to look at the code (it's not that easy though) see http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/xre/nsAppRunner.cpp#3220 for the extensions.ini thing and http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/xre/nsAppRunner.cpp#3379 for where the code is that determinates the restart maybe you want to set a breakpoint there if you have the source
Crash if I rename extensions.ini
I moved extensions.ini out of the way and got a crash
Fastload
mook_sb points out:
- skierpage: you may want to try to delete (one at a time, to narrow things down) compreg.dat, xul.mfasl, xpc.mfasl) to see if fastload files are the problem. -safe-mode disables/enables extensions so they get regenerated in that case.
Moved compreg.dat out of the way -> still immediate exit. I did get a new compreg.dat and prefs.js
Moved XUL.mfasl out of the way -> still immediate exit. I got only a new, unchanged, prefs.js.
Moved XPC.mfasl out of the way -> still immediate exit. I got only a new, unchanged, prefs.js.
Hmmm.