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)
Core Graveyard
Web Services
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.8alpha5
People
(Reporter: timeless, Assigned: bzbarsky)
Details
(Keywords: assertion)
Attachments
(1 file)
|
1.45 KB,
patch
|
jst
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
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
| Assignee | ||
Comment 2•20 years ago
|
||
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?
| Assignee | ||
Comment 3•20 years ago
|
||
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.| Assignee | ||
Comment 5•20 years ago
|
||
| Assignee | ||
Comment 6•20 years ago
|
||
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 7•20 years ago
|
||
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 | ||
Updated•20 years ago
|
Assignee: web-services → bzbarsky
OS: Windows XP → All
Priority: -- → P2
Hardware: PC → All
Target Milestone: --- → mozilla1.8alpha5
| Assignee | ||
Comment 8•20 years ago
|
||
Fixed.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•