The default bug view has changed. See this FAQ.

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

VERIFIED FIXED

Status

()

Core
XPCOM
--
critical
VERIFIED FIXED
8 years ago
6 years ago

People

(Reporter: bc, Assigned: dbaron)

Tracking

(4 keywords)

1.9.0 Branch
x86
All
crash, regression, testcase, verified1.9.0.11
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.0.11 +
wanted1.9.0.x +
wanted1.8.1.x -
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical?] 1.9.0 branch, crash signature)

(Reporter)

Description

8 years ago
+++ 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 1.9.0.4
Flags: blocking1.9.0.11? → blocking1.9.0.12?
Keywords: qawanted
(Reporter)

Comment 2

8 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
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?]

Updated

8 years ago
Whiteboard: [sg:critical?] → [sg:critical?] 1.9.0 branch
(Assignee)

Comment 4

8 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

8 years ago
This looks a lot like bug 489041.
(Assignee)

Comment 6

8 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

8 years ago
My guess would be that porting the fix for bug 421576 will fix this.
(Assignee)

Comment 8

8 years ago
Transplanting the fix for bug 421576 fixes this and bug 489041.
Depends on: 421576
Flags: blocking1.9.0.12? → blocking1.9.0.11+
(Assignee)

Comment 9

8 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
Last Resolved: 8 years ago
Keywords: fixed1.9.0.11
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
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

Comment 13

8 years ago
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.