Closed Bug 284587 Opened 19 years ago Closed 19 years ago

###!!! ASSERTION: Trying to continue parsing on a unblocked parser.: '!(mFlags & NS_PARSER_FLAG_PARSER_ENABLED)', file r:/mozilla/parser/htmlparser/src/nsParser.cpp, line 1418

Categories

(Core :: CSS Parsing and Computation, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: timeless, Assigned: mrbkap)

References

()

Details

(Keywords: assertion)

Attachments

(1 file)

bug 220542 bug 243338

CSS Error (http://www.olympic.org/common/css/style.css :66.13): Error in parsing
 value for property 'cursor'.  Declaration dropped.
Parse Time (this=08DAD1D0): Real time 0:0:0.16, CP time 0.016
DTD Time: Real time 0:0:12.375, CP time 0.813
Tokenize Time: Real time 0:0:0.16, CP time 0.016
###!!! ASSERTION: Trying to continue parsing on a unblocked parser.: '!(mFlags &
 NS_PARSER_FLAG_PARSER_ENABLED)', file
r:/mozilla/parser/htmlparser/src/nsParser.cpp, line 1418
Break: at file r:/mozilla/parser/htmlparser/src/nsParser.cpp, line 1418

 	xpcom_core.dll!nsDebug::Assertion(const char * aStr=0x02521030, const char *
aExpr=0x02521004, const char * aFile=0x02520fd4, int aLine=1418)  Line 109	C++
 	gkparser.dll!nsParser::ContinueParsing()  Line 1418 + 0x29	C++
 	gklayout.dll!CSSLoaderImpl::SheetComplete(SheetLoadData *
aLoadData=0x08894c20, int aSucceeded=1)  Line 1521	C++
 	gklayout.dll!CSSLoaderImpl::ParseSheet(nsIUnicharInputStream *
aStream=0x08945af8, SheetLoadData * aLoadData=0x08894c20, int & aCompleted=1)
 Line 1456	C++
 	gklayout.dll!SheetLoadData::OnStreamComplete(nsIUnicharStreamLoader *
aLoader=0x0883d0b0, nsISupports * aContext=0x00000000, unsigned int aStatus=0,
nsIUnicharInputStream * aDataStream=0x08945af8)  Line 801 + 0x17	C++
 	necko.dll!nsUnicharStreamLoader::OnStopRequest(nsIRequest *
request=0x06e17f60, nsISupports * ctxt=0x00000000, unsigned int aStatus=0) 
Line 196	C++
 	necko.dll!nsStreamListenerTee::OnStopRequest(nsIRequest * request=0x06e17f60,
nsISupports * context=0x00000000, unsigned int status=0)  Line 66	C++
 	necko.dll!nsHttpChannel::OnStopRequest(nsIRequest * request=0x075d9ae0,
nsISupports * ctxt=0x00000000, unsigned int status=0)  Line 3814	C++
 	necko.dll!nsInputStreamPump::OnStateStop()  Line 507	C++
 	necko.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream *
stream=0x0b7bca10)  Line 343 + 0xb	C++
 	xpcom_core.dll!nsInputStreamReadyEvent::EventHandler(PLEvent *
plevent=0x0a07c454)  Line 119	C++
 	xpcom_core.dll!PL_HandleEvent(PLEvent * self=0x0a07c454)  Line 698 + 0xa	C
 	xpcom_core.dll!PL_ProcessPendingEvents(PLEventQueue * self=0x00bce008)  Line
633 + 0x9	C
 	xpcom_core.dll!nsEventQueueImpl::ProcessPendingEvents()  Line 413 + 0xc	C++
 	gkwidget.dll!nsWindow::DispatchPendingEvents()  Line 3837	C++
 	gkwidget.dll!nsWindow::ProcessMessage(unsigned int msg=512, unsigned int
wParam=1, long lParam=786463, long * aRetValue=0x0012fc7c)  Line 4130	C++
 	gkwidget.dll!nsWindow::WindowProc(HWND__ * hWnd=0x00070cb6, unsigned int
msg=512, unsigned int wParam=1, long lParam=786463)  Line 1419 + 0x1b	C++
 	user32.dll!_InternalCallWinProc@20()  + 0x28	
 	user32.dll!_UserCallWinProcCheckWow@32()  + 0xb7	
 	user32.dll!_DispatchMessageWorker@8()  + 0xdc	
 	user32.dll!_DispatchMessageW@4()  + 0xf	
 	gkwidget.dll!nsAppShell::Run()  Line 135	C++
 	appcomps.dll!nsAppStartup::Run()  Line 207	C++
 	mozilla.exe!main1(int argc=1, char * * argv=0x00347a98, nsISupports *
nativeApp=0x00bbbfb8)  Line 1324 + 0x20	C++
 	mozilla.exe!main(int argc=1, char * * argv=0x00347a98)  Line 1825 + 0x25	C++
 	mozilla.exe!mainCRTStartup()  Line 398 + 0x11	C
 	kernel32.dll!_BaseProcessStart@4()  + 0x23	

+
{,,necko.dll}((*(nsACString*)(&(*(nsCSubstring*)(&(*(nsStandardURL*){*}(((*aLoadData).mURI).mRawPtr)).mSpec))))).mData
0x0777f240
"http://www4.mercedes-benz.com/emb/lang_select/be/css/ext_style_ie.css"	char *
Boris, the <link> in question here is part of the output of a document.write().
I suspect that we're blocking the parser for the <link> load and somehow
re-enable the parser before the stylesheet actually loads, but I can't support
this with code (in fact, the code seems to contradict this).
Can probably check by putting breakpoints in the methods where we block and
restore the parser (after breaking the first time in the nsHTMLDocument::Write
call)...
Attached patch patch v1Splinter Review
Question: How can the parser do unblocked things (like call DidBuildModel())
after being blocked?
Answer: The parser wasn't blocked.

I ran into this, and after lots and lots of thinking and breakpoints and
printf()s all over the place, I found what looks to be the culprit: we weren't
actually blocking the parser for the <link> load. Instead, we were interrupting
the parser, so when the style link loaded (successfully or not), we would try
unblocking an unblocked parser, since we'd lost the original request to block
it.

With this patch, we don't lose the request to block the parser if we hit the
magical time to interrupt.
Assignee: dbaron → mrbkap
Status: UNCONFIRMED → ASSIGNED
Attachment #177268 - Flags: superreview?(bzbarsky)
Attachment #177268 - Flags: review?(jst)
Comment on attachment 177268 [details] [diff] [review]
patch v1

Good catch!  sr=bzbarsky
Attachment #177268 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 177268 [details] [diff] [review]
patch v1

r=jst
Attachment #177268 - Flags: review?(jst) → review+
The fix for this was checked in, accidentally, as part of my checkin for bug 285250.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: