Bug 110546 - ASSERTION FAILED: m_tokenizer.isInDataState() in WebCore::HTMLDocumentParser::pumpTokenizer
Summary: ASSERTION FAILED: m_tokenizer.isInDataState() in WebCore::HTMLDocumentParser:...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 111449 112216 135599 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-02-21 19:42 PST by Tony Gentilcore
Modified: 2016-03-11 02:10 PST (History)
6 users (show)

See Also:


Attachments
Test case (185 bytes, text/html)
2013-02-21 19:42 PST, Tony Gentilcore
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tony Gentilcore 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.
Comment 1 Eric Seidel (no email) 2013-02-22 10:41:07 PST
I assume this affects both the main thread parser and the background parser?
Comment 2 Adam Barth 2013-02-22 10:48:07 PST
Yeah.
Comment 3 Adam Barth 2013-03-05 11:41:59 PST
*** Bug 111449 has been marked as a duplicate of this bug. ***
Comment 4 Dean Jackson 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.
Comment 5 Eric Seidel (no email) 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. :(
Comment 6 Dean Jackson 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)
Comment 7 Eric Seidel (no email) 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
Comment 8 Eric Seidel (no email) 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.
Comment 9 Eric Seidel (no email) 2013-03-11 23:01:41 PDT
I happened to fix this for the threaded parser as part of bug 112069.
Comment 10 Alexey Proskuryakov 2013-03-12 22:52:52 PDT
*** Bug 112216 has been marked as a duplicate of this bug. ***
Comment 11 Simon Fraser (smfr) 2013-03-13 11:18:20 PDT
This assertion is continually happening on the bots. For that reason, it should be fixed or removed.
Comment 12 Adam Barth 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.
Comment 13 Eric Seidel (no email) 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.
Comment 14 Simon Fraser (smfr) 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.
Comment 15 Eric Seidel (no email) 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.
Comment 16 Renata Hodovan 2016-03-11 02:08:16 PST
*** Bug 135599 has been marked as a duplicate of this bug. ***