Closed Bug 439206 Opened 12 years ago Closed 11 years ago
[FIX]Shutdown crash [@ PL
_DHash Table Finish] with high surrogate in <style>
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.
I'm hitting this crash frequently enough that it interferes with fuzzing.
jst, can you look at this?
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.
Component: Style System (CSS) → XPCOM
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>
Pushed changeset a06a5b54d548.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Attachment #336544 - Flags: approval220.127.116.11?
Comment on attachment 336544 [details] [diff] [review] Fix Approved for 18.104.22.168, a=dveditz for release-drivers
Attachment #336544 - Flags: approval22.214.171.124? → approval126.96.36.199+
Fixed on branch.
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.
Flags: blocking1.9.1? → blocking1.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.
You can verify this with a debug build, per comment 8.
I verified this for 1.9.0 using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:188.8.131.52pre) Gecko/2009040612 Minefield/3.0.10pre (my own debug build from last week).
You need to log in before you can comment on or make changes to this bug.