libc or firefox bug?

[Martin Olsson]

I just ran into a firefox freeze on jaunty. I had a pretty big session up (around 20 windows) and I don't have repro steps for it.
However, still I wanted to let you see the stack I saw inside Firefox.

Clearly glibc understood that something really fishy was going on but it seems to me that glibc did something risky
while trying to abort the process. Well actually I think it's Firefox that has some signal handler register and that
this signal handler calls into libc which then takes some lock, which in my case was already held. So maybe there is
some rule in some standard somewhere that says you can do certain things when you're executing from a signal handler
during process teardown? Or, it could also be a bug in libc where __GI___libc_free() takes some lock during the
first time it's being call and the libc authors just didn't think about the semi-absurd possibility that the function
__GI___libc_free() might actually call itself in this extreme case when the process teardown is happening.


(gdb) bt
#0  __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:91
#1  0x00007f15f877a025 in _L_lock_4783 () from /lib/libc.so.6
#2  0x00007f15f877626b in *__GI___libc_free (mem=0x7f15f8a69a00) at malloc.c:3623
#3  0x00007f15f6ecd280 in nsProfileLock::Unlock (this=0x10b89e8) at nsProfileLock.cpp:658
#4  0x00007f15f6ecd2b5 in nsProfileLock::RemovePidLockFiles () at nsProfileLock.cpp:150
#5  0x00007f15f6ecd466 in nsProfileLock::FatalSignalHandler (signo=-123299328) at nsProfileLock.cpp:165
#6  <signal handler called>
#7  0x00007f15f872efb5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#8  0x00007f15f8730bc3 in *__GI_abort () at abort.c:88
#9  0x00007f15f876e228 in __libc_message (do_abort=2, fmt=0x7f15f8838488 "*** glibc detected *** %s: %s: 0x%s ***\n")
     at ../sysdeps/unix/sysv/linux/libc_fatal.c:170
#10 0x00007f15f8773cb8 in malloc_printerr (action=2, str=0x7f15f8838590 "double free or corruption (!prev)", ptr=<value optimized out>)
     at malloc.c:5994
#11 0x00007f15f8776276 in *__GI___libc_free (mem=0x7f15f882e8a0) at malloc.c:3625
#12 0x00007f15f84c741d in js_FinalizeStringRT (rt=0x10d1e80, str=0x1b9e800, type=6, cx=0x7f15f882e8a0) at jsstr.c:2653
#13 0x00007f15f848605b in js_GC (cx=0x19531f0, gckind=GC_NORMAL) at jsgc.c:3349
#14 0x00007f15f6ed2cdd in nsXPConnect::Collect (this=0x10d96d0) at nsXPConnect.cpp:529
#15 0x00007f15f7652bec in nsCycleCollector::Collect (this=0x7f15f96de010, aTryCollections=1) at nsCycleCollector.cpp:2250
#16 0x00007f15f725c139 in nsJSContext::CC () at nsJSEnvironment.cpp:3346
#17 0x00007f15f725c1f0 in nsJSContext::MaybeCC (aHigherProbability=1) at nsJSEnvironment.cpp:3397
#18 0x00007f15f725c363 in nsJSContext::Notify (this=0xca31730, timer=<value optimized out>) at nsJSEnvironment.cpp:3438
#19 0x00007f15f764b2c6 in nsTimerImpl::Fire (this=0xb3c31e0) at nsTimerImpl.cpp:403
#20 0x00007f15f764b3c6 in nsTimerEvent::Run (this=<value optimized out>) at nsTimerImpl.cpp:490
#21 0x00007f15f76494b2 in nsThread::ProcessNextEvent (this=0x10b66c0, mayWait=1, result=0x7fff0185480c) at nsThread.cpp:510
#22 0x00007f15f761e6e6 in NS_ProcessNextEvent_P (thread=0x10fe, mayWait=1) at nsThreadUtils.cpp:227
#23 0x00007f15f75a2dd1 in nsBaseAppShell::Run (this=0x15bd560) at nsBaseAppShell.cpp:170
#24 0x00007f15f7442751 in nsAppStartup::Run (this=0x1886c70) at nsAppStartup.cpp:181
#25 0x00007f15f6ec8062 in XRE_main (argc=<value optimized out>, argv=<value optimized out>, aAppData=<value optimized out>) at nsAppRunner.cpp:3213
#26 0x00000000004016b4 in ?? ()
#27 0x00007f15f871a5a6 in __libc_start_main (main=0x40131e <_Znwm at plt+422>, argc=2, ubp_av=0x7fff01858208, init=0x405830 <_Znwm at plt+18104>,
     fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7fff018581f8) at libc-start.c:220
#28 0x00000000004011b9 in ?? ()
#29 0x00007fff018581f8 in ?? ()