User:Skierpage/Firefox early exit: Difference between revisions

    From KDE UserBase Wiki
     
    (4 intermediate revisions by the same user not shown)
    Line 9: Line 9:
    In #developers, mook_sb suggested that Firefox's
    In #developers, mook_sb suggested that Firefox's


    == Debugging in gdb ==
    == 2010-12-30 work ==
    firefox -g starts in gdb. I enabled catch syscall (Kubuntu launchpad bug filed) and entered
    === 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
       catch syscall exit_group


    Line 58: Line 65:
    #21 0x0000000000000000 in ?? ()</pre>
    #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.
    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. http://www.rafkind.com/jon/showproject.php?id=34 has a simple dlopen test program.


    == Start-up issues ==
    ==== 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
    mcsmurf points out
    Line 73: Line 111:
    maybe you want to set a breakpoint there if you have the source
    maybe you want to set a breakpoint there if you have the source


    === Crash if I rename extensions.ini ===
    ==== Crash if I rename extensions.ini ====
    I moved extensions.ini out of the way and got a crash
    I moved extensions.ini out of the way and got a crash


    === Fastload ===
    ==== Fastload ====
    mook_sb points out:
    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.
    : 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.
    Line 86: Line 124:
    Moved XPC.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.
    Removing prefs.js made it work, once only.
     
    Tried adding [ http://kb.mozillazine.org/Nglayout.debug.disable_xul_fastload 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.

    Latest revision as of 01:44, 17 May 2010

    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 "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. http://www.rafkind.com/jon/showproject.php?id=34 has a simple dlopen test program.

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

    Removing prefs.js made it work, once only.

    Tried adding [ http://kb.mozillazine.org/Nglayout.debug.disable_xul_fastload 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.