Summary: | REGRESSION (r68289): Assertion failure in StringHasher::addCharacter() (ch != invalidCharacterValue) running websocket/tests/bad-sub-protocol-non-ascii.html | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | mitz | ||||
Component: | JavaScriptCore | Assignee: | Patrick R. Gansterer <paroga> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | barraclough, commit-queue, mihaip, paroga | ||||
Priority: | P1 | Keywords: | LayoutTestFailure, Regression | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Attachments: |
|
Description
mitz
2010-09-24 22:42:41 PDT
Created attachment 68815 [details]
Patch
Comment on attachment 68815 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=68815&action=review I see. We're just talking about FFFE. > JavaScriptCore/ChangeLog:7 > + REGRESSION (r68289): Assertion failure in StringHasher::addCharacter() (ch != invalidCharacterValue) > + running websocket/tests/bad-sub-protocol-non-ascii.html > + https://bugs.webkit.org/show_bug.cgi?id=46553 Thanks. This bug was troubling me. > JavaScriptCore/ChangeLog:9 > + Because we use StringHasher for binary data too, so the check for invalid unicode input is wrong. Why are we using StringHasher for binary data? String is supposed to represent a UTF16 string. Comment on attachment 68815 [details] Patch Clearing flags on attachment: 68815 Committed r68368: <http://trac.webkit.org/changeset/68368> All reviewed patches have been landed. Closing bug. (In reply to comment #3) > Why are we using StringHasher for binary data? I don't know! > String is supposed to represent a UTF16 string. That's why I used FFFE. IMHO using StringHasher for creating a hash of binary data is no problem (see bug 46514). |