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. 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.
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.