Bug 54418 - r78499 causes assertion failure in http/tests/xmlhttprequest/cache-override.html
Summary: r78499 causes assertion failure in http/tests/xmlhttprequest/cache-override.html
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Text (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Darin Adler
URL:
Keywords:
Depends on:
Blocks: 53898
  Show dependency treegraph
 
Reported: 2011-02-14 15:45 PST by Peter Kasting
Modified: 2011-02-15 11:31 PST (History)
4 users (show)

See Also:


Attachments
check for zero (1.31 KB, patch)
2011-02-15 02:42 PST, Antti Koivisto
kling: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Kasting 2011-02-14 15:45:21 PST
Chromium bots started crashing on this test after r78499 went in (see our test dashboard at http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showExpectations=true&group=%40ToT%20-%20chromium.org&tests=http%2Ftests%2Fxmlhttprequest%2Fcache-override.html ).

The critical bit is this chunk I copied from the Linux run:

ASSERTION FAILED: count > m_partialSequenceSize
third_party/WebKit/Source/WebCore/platform/text/TextCodecUTF8.cpp(217) : virtual WTF::String WebCore::TextCodecUTF8::decode(const char*, size_t, bool, bool, bool&)
[14203:14203:2241232273962:ERROR:process_util_posix.cc(106)] Received signal 11
Comment 1 Mario Sanchez Prada 2011-02-15 02:05:10 PST
It's also causing crashes in SnowLeopard and GTK bots.

See full backtrace as got from the GTK 32-bit debug bot in my last comment in bug 53898:
https://bugs.webkit.org/show_bug.cgi?id=53898#c56
Comment 2 Antti Koivisto 2011-02-15 02:42:09 PST
Created attachment 82431 [details]
check for zero
Comment 3 Andreas Kling 2011-02-15 02:53:07 PST
Comment on attachment 82431 [details]
check for zero

r=me
Comment 4 Antti Koivisto 2011-02-15 02:54:19 PST
Comment on attachment 82431 [details]
check for zero

Hmm, no this is not correct. It should still flush the partial sequence and set the error flag. Better leave it for Darin.
Comment 5 Andreas Kling 2011-02-15 02:58:08 PST
Comment on attachment 82431 [details]
check for zero

re-r+ing again as agreed on IRC.
I don't see a problem with this patch, TextCodecUTF16 has the same check.
Comment 6 Antti Koivisto 2011-02-15 03:10:03 PST
http://trac.webkit.org/changeset/78541

I also filed

https://bugs.webkit.org/show_bug.cgi?id=54444
Correct handling of end of buffer partial sequence in UFT8 decoder when flushing with zero length
Comment 7 Peter Kasting 2011-02-15 11:31:06 PST
(For clarity, the patch here landed in r78541)