Closed
Bug 490513
Opened 15 years ago
Closed 15 years ago
Shutdown crash [@ PL_DHashTableFinish] with high surrogate in <style>
Categories
(Core :: XPCOM, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: bc, Assigned: dbaron)
References
Details
(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?
Comment 1•15 years ago
|
||
qawanted: I'm not seeing this crash on Mac. Is it windows only? bug 439206 is supposed to be fixed in 1.9.0.4
Flags: blocking1.9.0.11? → blocking1.9.0.12?
Keywords: qawanted
Reporter | ||
Comment 2•15 years ago
|
||
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
Comment 3•15 years ago
|
||
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)
Updated•15 years ago
|
Whiteboard: [sg:critical?] → [sg:critical?] 1.9.0 branch
Assignee | ||
Comment 4•15 years ago
|
||
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.
Assignee | ||
Comment 5•15 years ago
|
||
This looks a lot like bug 489041.
Assignee | ||
Comment 6•15 years ago
|
||
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.
Assignee | ||
Comment 7•15 years ago
|
||
My guess would be that porting the fix for bug 421576 will fix this.
Assignee | ||
Comment 8•15 years ago
|
||
Transplanting the fix for bug 421576 fixes this and bug 489041.
Assignee | ||
Comment 9•15 years ago
|
||
Fixed on CVS trunk (for 1.9.0.11) by landing of bug 421576, 2009-05-06 18:33 -0700. Thanks to jst, jwalden, and dveditz for helping.
Assignee: nobody → dbaron
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: fixed1.9.0.11
Resolution: --- → FIXED
Comment 10•15 years ago
|
||
Verified fixed for 1.9.0.11 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11pre) Gecko/2009051111 GranParadiso/3.0.11pre after seeing it crash for 1.9.0.10 on OS X. I could not get it to crash on Linux with 1.9.0.10 with the attached testcase.
Keywords: fixed1.9.0.11 → verified1.9.0.11
Updated•15 years ago
|
Status: RESOLVED → VERIFIED
Comment 12•15 years ago
|
||
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.
Updated•15 years ago
|
Group: core-security
Comment 13•15 years ago
|
||
Since this bug involved bug 439206's testcase, bug 439206 being in-testsuite+ makes this in-testsuite+.
Flags: in-testsuite+
Updated•13 years ago
|
Crash Signature: [@ PL_DHashTableFinish]
You need to log in
before you can comment on or make changes to this bug.
Description
•