| 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: |
|
||||||
I assume this affects both the main thread parser and the background parser? Yeah. *** Bug 111449 has been marked as a duplicate of this bug. *** 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. (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. :( (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) webkit.org/b/110546 [ Debug ] fast/parser/document-write-fighting-eof.html [ Crash ] Is probably the line we should have added to LayoutTests/TestExpectations (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. I happened to fix this for the threaded parser as part of bug 112069. *** Bug 112216 has been marked as a duplicate of this bug. *** This assertion is continually happening on the bots. For that reason, it should be fixed or removed. (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. 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. 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. (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. *** Bug 135599 has been marked as a duplicate of this bug. *** 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? |
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.