User:Skierpage/Firefox early exit

From KDE UserBase Wiki
Revision as of 01:44, 17 May 2010 by Skierpage (talk | contribs) (→‎2010-05-16 debugging build)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

2010-12-30 work

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 "",
    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 "", 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/
#11 0x00007ffff58b2e90 in PR_LoadLibrary () from /home/skierpage/programs/firefox/
#12 0x00007ffff691f2e5 in ?? () from /home/skierpage/programs/firefox/
#13 0x00007ffff691844b in XRE_main () from /home/skierpage/programs/firefox/
#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 , maybe there's a way to break on load of that and see if that's really the problem. has a simple dlopen test program.

= test

I tried

 break _dl_map_object
 with commands
 >echo break in _dl_map_object
 >print name

and also

 break _dl_map_object if name=""

then ran with this. Lots of _dl_map_objects, including lots in Then

 Breakpoint 4, _dl_map_object (loader=0x7ffff7fc31e0, name=0x7ffff7fc11f8 "", 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 ""
Inconsistency detected by dl-version.c: 230: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed!
Program exited with code 0177.

Hmm, was that really in

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 for the extensions.ini thing and 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


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.

Removing prefs.js made it work, once only.

Tried adding [ nglayout.debug.disable_xul_fastload]=true and other settings to about:config, didn't help.

2010-05-16 debugging build

Still happening, though with upgrade to Lucid Lynx, I don't get the

 GLib-WARNING **: g_set_prgname() called multiple times

any more.

I downloaded a debugging build. See ~/debugging/firefox_exists_debugbuild.log for it failing

Couldn't get it to fail with a different simpler profile, even after I stopped specifying -P and let it remember that profile. Hmmm.