libc or firefox bug?

[Martin Olsson]

Done. The issue was filed here:
https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/354545


John Vivirito wrote:
> On 04/03/2009 09:39 AM, Martin Olsson wrote:
>> 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 ?? ()
>>
>>
>>   
> Please file a bug against Firefox-3.0 that way we can track it and
> figure out where the issue is. If you would so kind to drop the bug
> report link to this mailing list it would help us.
> I get the feeling I've seen this before on another bug report.
>