Last Comment Bug 490513 - Shutdown crash [@ PL_DHashTableFinish] with high surrogate in <style>
: Shutdown crash [@ PL_DHashTableFinish] with high surrogate in <style>
Status: VERIFIED FIXED
: [sg:critical?] 1.9.0 branch
: crash, regression, testcase, verified1.9.0.11
Product: Core
Classification: Components
Component: XPCOM
: 1.9.0 Branch
: x86 All
: -- critical (vote)
: ---
Assigned To: David Baron [:dbaron]
: xpcom
:
: 421576 439206
:
  Show dependency treegraph
 
Reported: 2009-04-28 11:14 PDT by Bob Clary [:bc:]
Modified: 2009-06-12 18:52 PDT (History)
10 users (show)
dveditz: blocking1.9.0.11+
dveditz: wanted1.9.0.x+
dveditz: wanted1.8.1.x-
jruderman: in‑testsuite+
See Also:
Crash Signature:
[@ PL_DHashTableFinish]


Attachments

Summon comment box

Description Bob Clary [:bc:] 2009-04-28 11:14:42 PDT
+++ 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
Comment 1 Daniel Veditz 2009-05-04 13:34:04 PDT
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
Comment 2 Bob Clary [:bc:] 2009-05-04 14:00:44 PDT
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
Comment 3 Daniel Veditz 2009-05-04 14:37:57 PDT
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)
Comment 4 David Baron [:dbaron] 2009-05-06 16:41:40 PDT
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.
Comment 5 David Baron [:dbaron] 2009-05-06 18:01:01 PDT
This looks a lot like bug 489041.
Comment 6 David Baron [:dbaron] 2009-05-06 18:06:26 PDT
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.
Comment 7 David Baron [:dbaron] 2009-05-06 18:07:59 PDT
My guess would be that porting the fix for bug 421576 will fix this.
Comment 8 David Baron [:dbaron] 2009-05-06 18:21:36 PDT
Transplanting the fix for bug 421576 fixes this and bug 489041.
Comment 9 David Baron [:dbaron] 2009-05-06 18:36:39 PDT
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.
Comment 10 Al Billings [:abillings] 2009-05-11 14:18:45 PDT
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.
Comment 11 Daniel Veditz 2009-05-29 10:49:51 PDT
Doesn't appear to affect the 1.8 branch
Comment 12 Jeff Walden (remove +bmo to email) 2009-06-10 22:43:39 PDT
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.
Comment 13 Jesse Ruderman 2009-06-12 18:52:43 PDT
Since this bug involved bug 439206's testcase, bug 439206 being in-testsuite+ makes this in-testsuite+.

Note You need to log in before you can comment on or make changes to this bug.