Closed Bug 439206 Opened 16 years ago Closed 15 years ago

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

Categories

(Core :: XPCOM, defect, P1)

x86
macOS
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: jruderman, Assigned: bzbarsky)

References

Details

(5 keywords, Whiteboard: [sg:critical?])

Crash Data

Attachments

(2 files)

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1a1pre) Gecko/2008061310 Minefield/3.1a1pre

Loading the testcase and then quitting Firefox (Cmd+Q) usually results in a crash:

* PL_DHashTableFinish calling a random address
* PL_DHashTableFinish calling AtomTableClearEntry, which dereferences a random address

The problem clearly starts with bug 316338, but I think there's a recent regression in how the style system or the atom table deals with it.
Group: security
Whiteboard: [sg:critical?]
I'm hitting this crash frequently enough that it interferes with fuzzing.
Flags: blocking1.9.1?
jst, can you look at this?
Attached patch FixSplinter Review
The issue was that we added the atom to the table with one hashcode (as computed via HashCodeAsUTF8) but tried to remove it using the hashcode of the UTF-8 string stored in the atom when the atom went away.  These should be the same, but there was a bug in HashCodeAsUTF8 that caused them to differ in the missing-low-surrogate case, which left a pointer to the dead atom in the atom table, and hence a shutdown crash.

This patch just fixes that bug, making this code consistent with what the ConvertUTF16toUTF8 function and the UTF16CharEnumerator do.

We probably want this patch on 1.9.0.x.
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #336544 - Flags: superreview?(jst)
Attachment #336544 - Flags: review?(jst)
Component: Style System (CSS) → XPCOM
Flags: blocking1.9.0.3?
QA Contact: style-system → xpcom
Summary: Shutdown crash [@ PL_DHashTableFinish] with high surrogate in <style> → [FIX]Shutdown crash [@ PL_DHashTableFinish] with high surrogate in <style>
Attachment #336544 - Flags: superreview?(jst)
Attachment #336544 - Flags: superreview+
Attachment #336544 - Flags: review?(jst)
Attachment #336544 - Flags: review+
Pushed changeset a06a5b54d548.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Attachment #336544 - Flags: approval1.9.0.3?
Flags: blocking1.9.0.3? → blocking1.9.0.3+
Comment on attachment 336544 [details] [diff] [review]
Fix

Approved for 1.9.0.3, a=dveditz for release-drivers
Attachment #336544 - Flags: approval1.9.0.3? → approval1.9.0.3+
Fixed on branch.
Keywords: fixed1.9.0.3
I cannot get 3.0.3 to crash with this test case on either OS X or Windows XP. How reliable is the crash?
It was about every other time or so for me on trunk with a debug build...  I suspect opt builds it would happen less commonly.
Group: core-security
Flags: in-testsuite+
Flags: blocking1.9.1? → blocking1.9.1+
Keywords: fixed1.9.1
Priority: -- → P1
Seeing as there hasn't been any discussions about this bug for 5 1/2 months and it's been in mochitest for that long, I'm assuming there aren't any residual issues. I'm moving this to verified as a result. If anyone has any qualms, feel free to bring them up.
Status: RESOLVED → VERIFIED
You can verify this with a debug build, per comment 8.
Status: VERIFIED → RESOLVED
Closed: 16 years ago15 years ago
I verified this for 1.9.0 using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.10pre) Gecko/2009040612 Minefield/3.0.10pre (my own debug build from last week).
Blocks: 490513
Crash Signature: [@ PL_DHashTableFinish]
You need to log in before you can comment on or make changes to this bug.