Closed Bug 490513 Opened 12 years ago Closed 12 years ago

Shutdown crash [@ PL_DHashTableFinish] with high surrogate in <style>


(Core :: XPCOM, defect)

1.9.0 Branch
Not set





(Reporter: bc, Assigned: dbaron)



(4 keywords, Whiteboard: [sg:critical?] 1.9.0 branch)

Crash Data

+++ This bug was initially created as a clone of Bug #439206 +++

Created an attachment (id=325076)
testcase (makes Firefox crash on shutdown)

This bug is marked fixed on 1.9.0 but it still crashes for me on winxp with 
dom/base/crashtests/439206-1.html (from trunk)

1.9.0 !exploitable report
PROBABLY_EXPLOITABLE: Probably Exploitable - Data from Faulting Address controls Code Flow starting at xpcom_core!AtomTableClearEntry
Flags: blocking1.9.0.11?
qawanted: I'm not seeing this crash on Mac. Is it windows only? bug 439206 is supposed to be fixed in
Flags: blocking1.9.0.11? → blocking1.9.0.12?
Keywords: qawanted
mac os x for me with a build from this morning:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000025
0x002de37e in AtomTableClearEntry (table=0x3a6700, entry=0x177c7660) at /work/mozilla/builds/1.9.0/mozilla/xpcom/ds/nsAtomTable.cpp:325
325	    if (atom->IsPermanent()) {
(gdb) bt
#0  0x002de37e in AtomTableClearEntry (table=0x3a6700, entry=0x177c7660) at /work/mozilla/builds/1.9.0/mozilla/xpcom/ds/nsAtomTable.cpp:325
#1  0x002c2a4c in PL_DHashTableFinish (table=0x3a6700) at pldhash.c:373
#2  0x002ddda8 in NS_PurgeAtomTable () at /work/mozilla/builds/1.9.0/mozilla/xpcom/ds/nsAtomTable.cpp:414
#3  0x002da5d6 in NS_ShutdownXPCOM_P (servMgr=0x0) at /work/mozilla/builds/1.9.0/mozilla/xpcom/build/nsXPComInit.cpp:841
#4  0x000bc051 in ScopedXPCOMStartup::~ScopedXPCOMStartup (this=0xbfffe85c) at /work/mozilla/builds/1.9.0/mozilla/toolkit/xre/nsAppRunner.cpp:931
#5  0x000bc09f in ScopedXPCOMStartup::~ScopedXPCOMStartup (this=0xbfffe85c) at /work/mozilla/builds/1.9.0/mozilla/toolkit/xre/nsAppRunner.cpp:934
#6  0x000c2e18 in XRE_main (argc=3, argv=0xbfffead0, aAppData=0x60da70) at /work/mozilla/builds/1.9.0/mozilla/toolkit/xre/nsAppRunner.cpp:3237
#7  0x000026d3 in main (argc=3, argv=0xbfffead0) at /work/mozilla/builds/1.9.0/mozilla/browser/app/nsBrowserApp.cpp:158
OS: Windows XP → All
My bad, I had disabled JS in my test profile while testing something else. I definitely see this crash. (one I got was the somewhat scarier address 0x00000000c759a753)
Flags: wanted1.9.0.x+
Keywords: qawanted
Whiteboard: [sg:critical?]
Whiteboard: [sg:critical?] → [sg:critical?] 1.9.0 branch
I see this on Linux too.

The basic problem is that we create an atom for a string and then destroy it, but when we destroy it, it doesn't get removed from the atom table since the key we use doesn't match the key we added it with.
This looks a lot like bug 489041.
We could probably set things up so this asserts when the problem happens by having an assertion about gAtomTable.entryCount decreasing by 1 across the PL_DHashTableOperate in ~AtomImpl.
My guess would be that porting the fix for bug 421576 will fix this.
Transplanting the fix for bug 421576 fixes this and bug 489041.
Depends on: 421576
Flags: blocking1.9.0.12? → blocking1.9.0.11+
Fixed on CVS trunk (for by landing of bug 421576, 2009-05-06 18:33 -0700.

Thanks to jst, jwalden, and dveditz for helping.
Assignee: nobody → dbaron
Closed: 12 years ago
Keywords: fixed1.9.0.11
Resolution: --- → FIXED
Verified fixed for with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/2009051111 GranParadiso/3.0.11pre after seeing it crash for on OS X.

I could not get it to crash on Linux with with the attached testcase.
Doesn't appear to affect the 1.8 branch
Flags: wanted1.8.1.x-
See bug 489041 comment 9 for details of why this bug all but certainly was not present in 3.0, why it regressed in 3.0.x, and why bug 421576's patch fixed the problem when recently pushed.
Group: core-security
Since this bug involved bug 439206's testcase, bug 439206 being in-testsuite+ makes this in-testsuite+.
Flags: in-testsuite+
Crash Signature: [@ PL_DHashTableFinish]
You need to log in before you can comment on or make changes to this bug.