Closed Bug 268472 Opened 20 years ago Closed 20 years ago

###!!! ASSERTION: How'd we get here with an unknown type?: '!aParserContext.mMimeType.IsEmpty()', file r:/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 311

Categories

(Core Graveyard :: Web Services, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8alpha5

People

(Reporter: timeless, Assigned: bzbarsky)

Details

(Keywords: assertion)

Attachments

(1 file)

I'm loading file:///r:/mozilla/extensions/webservices/soap/tests/soapelements.html
and probably submitting some data (including confirming its security request)

###!!! ASSERTION: How'd we get here with an unknown type?:
'!aParserContext.mMimeType.IsEmpty()', file
r:/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 311
Break: at file r:/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 311

 	xpcom_core.dll!nsDebug::Assertion(const char * aStr=0x02080bdc, const char *
aExpr=0x02080c0c, const char * aFile=0x02081260, int aLine=0x00000137)  Line 109	C++
>	gkparser.dll!CNavDTD::CanParse(CParserContext & aParserContext={...})  Line
311 + 0x24	C++
 	gkparser.dll!FindSuitableDTD(CParserContext & aParserContext={...}, int *
aReturn=0x0012fbe0)  Line 1203	C++

+	((*(nsAString*)(&(*(nsSubstring*)(&aFilename))))).mData	0x030791c8
"http://213.23.125.181:8080/RPC"	unsigned short *

 	gkparser.dll!nsParser::WillBuildModel(nsString & aFilename={...})  Line 1290
+ 0xc	C++
 	gkparser.dll!nsParser::ResumeParse(int allowIteration=0x00000001, int
aIsFinalChunk=0x00000001, int aCanInterrupt=0x00000001)  Line 1865 + 0x13	C++
 	gkparser.dll!nsParser::OnStopRequest(nsIRequest * request=0x03020708,
nsISupports * aContext=0x00000000, unsigned int status=0x804b000e)  Line 2603	C++
 	xmlextras.dll!nsXMLHttpRequest::OnStopRequest(nsIRequest * request=0x03020708,
nsISupports * ctxt=0x00000000, unsigned int status=0x804b000e)  Line 1279 + 0x16	C++
 	necko.dll!nsHttpChannel::OnStopRequest(nsIRequest * request=0x02f5aff0,
nsISupports * ctxt=0x00000000, unsigned int status=0x804b000e)  Line 3760	C++
 	necko.dll!nsInputStreamPump::OnStateStop()  Line 505	C++
 	necko.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream *
stream=0x02e30d70)  Line 342	C++
 	xpcom_core.dll!nsInputStreamReadyEvent::EventHandler(PLEvent *
plevent=0x02f53cec)  Line 119	C++
 	xpcom_core.dll!PL_HandleEvent(PLEvent * self=0x02f53cec)  Line 693	C
 	xpcom_core.dll!PL_ProcessPendingEvents(PLEventQueue * self=0x01066650)  Line 628	C
 	xpcom_core.dll!_md_TimerProc(HWND__ * hwnd=0x00db1824, unsigned int
uMsg=0x00000113, unsigned int idEvent=0x00000000, unsigned long
dwTime=0x58eec844)  Line 998 + 0x6	C
 	user32.dll!77d43a50() 	
 	user32.dll!GetSysColor()  + 0x10f	
 	user32.dll!TranslateMessage()  + 0x8d	
 	user32.dll!DispatchMessageW()  + 0xb	
 	appcomps.dll!nsAppStartup::Run()  Line 221	C++
 	mozilla.exe!main1(int argc=0x0012fbe0, char * * argv=0x00000000, nsISupports *
nativeApp=0x02de5de8)  Line 1322	C++
 	mozilla.exe!main(int argc=0x00000001, char * * argv=0x003f7b80)  Line 1813 +
0x16	C++
 	mozilla.exe!mainCRTStartup()  Line 400 + 0x11	C
 	kernel32.dll!TermsrvAppInstallMode()  + 0x269	

+
{,,necko.dll}((*(nsACString*)(&(*(nsCSubstring*)(&(*(nsStandardURL*)(((*(nsHttpChannel*){*}request).mOriginalURI).mRawPtr)).mSpec))))).mData
0x00ff6ea8 "http://213.23.125.181:8080/RPC"	char *
+
{,,necko.dll}((*(nsACString*)(&(*(nsCSubstring*)(&(*(nsStandardURL*)(((*(nsHttpChannel*){*}request).mURI).mRawPtr)).mSpec))))).mData
0x00ff6ea8 "http://213.23.125.181:8080/RPC"	char *
followed by:
###!!! ASSERTION: How'd we get here with an unknown type?:
'!aParserContext.mMimeType.IsEmpty()', file
r:/mozilla/parser/htmlparser/src/nsExpatDriver.cpp, line 985

i entered "cl" as symbol and clicked next (followed by confirming the security
alert).
i may have clicked next and confirmed the security alert again
The problem here is that the mResponseHead on the HTTP channel is null, so
GetContentType throws.  Options include making up a random content type in the
parser when that happens and actually paying attention to the status of
OnStartRequest and not parsing if it's an error status...  Thoughts?
Alternately, maybe XMLHttpRequest should handle error statuses better... say at
nsXMLHttpRequest::OnStartRequest we could unset the XML_HTTP_REQUEST_PARSEBODY
flag if the request's status is a failure status, like we already do for non-XML
MIME types?

Heck, we could even unset it if GetContentType() (or SetContentType() when we
have an override) fails.  That would have the desired effect.
NS_IMETHODIMP
nsHttpChannel::GetContentType(nsACString &value)
{
    if (!mResponseHead) {
        // We got no data, we got no headers, we got nothing
        value.Truncate();
        return NS_ERROR_NOT_AVAILABLE;
    }

    if (!mResponseHead->ContentType().IsEmpty()) {
        value = mResponseHead->ContentType();
        return NS_OK;
    }

    
    value.AssignLiteral(UNKNOWN_CONTENT_TYPE);
    return NS_OK;
}
=============================

Re:
> The problem here is that the mResponseHead on the HTTP channel is null

From the code of GetContentType, a null |mResponseHead| means that it is
pointless to parse nothingness. Therefore I am fine with stopping that from
happening. Wichever approach is easier/safer/robust is fine by me. So go for
unsetting XML_HTTP_REQUEST_PARSEBODY when Get/SetContentType fails.
Comment on attachment 165295 [details] [diff] [review]
This should do it

With this patch, if the override is not set we'll get an empty type string, and
not parse.  If the override is set, we'll check the status and not parse if it
failed.
Attachment #165295 - Flags: superreview?(jst)
Attachment #165295 - Flags: review?(jst)
Comment on attachment 165295 [details] [diff] [review]
This should do it

r+sr=jst
Attachment #165295 - Flags: superreview?(jst)
Attachment #165295 - Flags: superreview+
Attachment #165295 - Flags: review?(jst)
Attachment #165295 - Flags: review+
Assignee: web-services → bzbarsky
OS: Windows XP → All
Priority: -- → P2
Hardware: PC → All
Target Milestone: --- → mozilla1.8alpha5
Fixed.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: