Bug 110546

Summary: ASSERTION FAILED: m_tokenizer.isInDataState() in WebCore::HTMLDocumentParser::pumpTokenizer
Product: WebKit Reporter: Tony Gentilcore <tonyg>
Component: WebCore Misc.Assignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: abarth, ahmad.saleem792, dino, eric, kadam, rhodovan.u-szeged, simon.fraser
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Test case none

Tony Gentilcore
Reported 2013-02-21 19:42:42 PST
Created attachment 189664 [details] Test case Write half of an entity and a beforeload handler and the other half in the script itself. See test case.
Attachments
Test case (185 bytes, text/html)
2013-02-21 19:42 PST, Tony Gentilcore 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1 2013-02-22 10:41:07 PST
I assume this affects both the main thread parser and the background parser?
Adam Barth
Comment 2 2013-02-22 10:48:07 PST
Yeah.
Adam Barth
Comment 3 2013-03-05 11:41:59 PST
*** Bug 111449 has been marked as a duplicate of this bug. ***
Dean Jackson
Comment 4 2013-03-06 16:07:01 PST
From the dupe "The appropriate thing is to mark the test as expected to crash until we fix that bug." Really? This is causing a crash on four ports. It seems like we should rollout https://bugs.webkit.org/show_bug.cgi?id=111365 http://trac.webkit.org/changeset/144714 rather than wait for a fix.
Eric Seidel (no email)
Comment 5 2013-03-06 16:09:40 PST
(In reply to comment #4) > From the dupe "The appropriate thing is to mark the test as expected to crash until we fix that bug." > > Really? This is causing a crash on four ports. It seems like we should rollout > https://bugs.webkit.org/show_bug.cgi?id=111365 > http://trac.webkit.org/changeset/144714 > > rather than wait for a fix. That change just added a test for this which was a known bug already. As noted in comment 2, this was an existing bug in the main-thread parser. We shouldn't have added a test w/o updating the Debug expectations to expect the ASSERT. :(
Dean Jackson
Comment 6 2013-03-06 16:16:02 PST
(In reply to comment #5) > That change just added a test for this which was a known bug already. As noted in comment 2, this was an existing bug in the main-thread parser. We shouldn't have added a test w/o updating the Debug expectations to expect the ASSERT. :( Got it. I added it to the Mac expectations https://trac.webkit.org/r144996 (I should learn how to do it for all debug builds)
Eric Seidel (no email)
Comment 7 2013-03-06 16:30:32 PST
webkit.org/b/110546 [ Debug ] fast/parser/document-write-fighting-eof.html [ Crash ] Is probably the line we should have added to LayoutTests/TestExpectations
Eric Seidel (no email)
Comment 8 2013-03-06 16:30:51 PST
(In reply to comment #7) > webkit.org/b/110546 [ Debug ] fast/parser/document-write-fighting-eof.html [ Crash ] > > Is probably the line we should have added to LayoutTests/TestExpectations Again, apologies for the disruption.
Eric Seidel (no email)
Comment 9 2013-03-11 23:01:41 PDT
I happened to fix this for the threaded parser as part of bug 112069.
Alexey Proskuryakov
Comment 10 2013-03-12 22:52:52 PDT
*** Bug 112216 has been marked as a duplicate of this bug. ***
Simon Fraser (smfr)
Comment 11 2013-03-13 11:18:20 PDT
This assertion is continually happening on the bots. For that reason, it should be fixed or removed.
Adam Barth
Comment 12 2013-03-13 11:55:15 PDT
(In reply to comment #11) > This assertion is continually happening on the bots. For that reason, it should be fixed or removed. My understanding is that this ASSERT is hit by one test. I would recommend marking the test as expected to crash in DEBUG.
Eric Seidel (no email)
Comment 13 2013-03-13 12:13:22 PDT
http://trac.webkit.org/browser/trunk/LayoutTests/fast/parser/document-write-fighting-eof.html Should be the only test to hit this ASSERT. There is a second test which will be added in bug 112069.
Simon Fraser (smfr)
Comment 14 2013-03-13 12:48:50 PDT
Making the test an expected CRASH doesn't avoid the test bot slowdown associated with generating a crash log, which is what I'm trying to avoid. Perhaps I should just skip the test in debug.
Eric Seidel (no email)
Comment 15 2013-03-13 14:35:34 PDT
(In reply to comment #14) > Making the test an expected CRASH doesn't avoid the test bot slowdown associated with generating a crash log, which is what I'm trying to avoid. Perhaps I should just skip the test in debug. Sorry, I forgot about how slow CrashReporter can be. You're right, many platforms probably just want to Skip tests which are expected to Crash. We can just mark these as Skip in debug, that seems fine.
Renata Hodovan
Comment 16 2016-03-11 02:08:16 PST
*** Bug 135599 has been marked as a duplicate of this bug. ***
Ahmad Saleem
Comment 17 2023-02-22 15:22:45 PST
I am not able to reproduce this assert failure in WebKit ToT build of 260689@main using MiniBrowser WK2 window. Do we need to track it further?
Note You need to log in before you can comment on or make changes to this bug.