View source for 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
<pre>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 ?? ()</pre>

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
<pre>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</pre>
: 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.