User:Skierpage/Firefox early exit

From KDE UserBase Wiki

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.