WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
110546
ASSERTION FAILED: m_tokenizer.isInDataState() in WebCore::HTMLDocumentParser::pumpTokenizer
https://bugs.webkit.org/show_bug.cgi?id=110546
Summary
ASSERTION FAILED: m_tokenizer.isInDataState() in WebCore::HTMLDocumentParser:...
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.
Top of Page
Format For Printing
XML
Clone This Bug