Closed
Bug 11112
Opened 26 years ago
Closed 25 years ago
Crash calling blocking read on nsHTTPChannel
Categories
(Core :: Networking, defect, P1)
Tracking
()
M10
People
(Reporter: dbaron, Assigned: waterson)
References
()
Details
I'm crashing in either of the following pages: http://www.fas.harvard.edu/~dbaron/nstmp/M9-2/when-com.xul http://www.fas.harvard.edu/~dbaron/nstmp/M9-2/stock-ticker.xul (access restricted to a few netscape domains and my domain...) My guess is RDF, but I'm on Windows and can't get a stack trace. Crash occurs in: * Windows, viewer & apprunner, 1999-08-01-16-M9 Does not occur in: * Windows, apprunner, 1999-07-27-12-M9
Assignee: chofmann → slamm
Component: other → Sidebar
Priority: P3 → P1
QA Contact: leger → paulmac
Summary: crash → Crash on load of customized sidebar panels.
Target Milestone: M9
Updated Summary. David, please put in full Summary info. Thanks! :-) Setting proper component, and updating QA Contact. Setting to M9 per don.
Reporter | ||
Updated•26 years ago
|
Assignee: slamm → waterson
Component: Sidebar → RDF
Summary: Crash on load of customized sidebar panels. → Crash on opening RDF datasource
Reporter | ||
Comment 2•26 years ago
|
||
Putting output statements in the JS shows that the line that crashes is: rdf_remote_datasource.Refresh(true); Changing component to RDF and assigning to waterson, and adding previous owner (slamm) to cc: list in case that is wrong.
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•26 years ago
|
Assignee: waterson → warren
Status: ASSIGNED → NEW
Component: RDF → Necko
Summary: Crash on opening RDF datasource → Crash synchronously opening an RDF/XML datasource from a remote location
Assignee | ||
Updated•26 years ago
|
Summary: Crash synchronously opening an RDF/XML datasource from a remote location → Crash calling blocking read on nsHTTPChannel
Assignee | ||
Comment 3•26 years ago
|
||
So it looks like you're trying to do a blocking parse on an HTTP URL (which, by the way, is evil -- you'll lock the UI up until DNS resolution happens, the URL gets loaded, etc.) The Necko HTTP protocol doesn't seem like it's quite ready to handle this case, I end up asserting in nsHTTPChannel::OpenStream() with this stack trace: nsHTTPChannel::OpenInputStream(nsHTTPChannel * const 0x0992edd0, unsigned int 0, int -1, nsIInputStream * * 0x0012e24c) line 168 + 21 bytes rdf_BlockingParse(nsIURI * 0x098eb670, nsIStreamListener * 0x0992ea94) line 555 + 40 bytes RDFXMLDataSourceImpl::Refresh(RDFXMLDataSourceImpl * const 0x098d63b4, int 1) line 915 + 26 bytes XPTC_InvokeByIndex(nsISupports * 0x098d63b4, unsigned int 4, unsigned int 1, nsXPTCVariant * 0x0012e430) line 135 nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x09789990, nsXPCWrappedNative * 0x098ea060, const XPCNativeMemberDescriptor * 0x098ea0d8, nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 1, long * 0x00d80f34, long * 0x0012e638) line 511 + 44 bytes WrappedNative_CallMethod(JSContext * 0x09789990, JSObject * 0x00d7e2a8, unsigned int 1, long * 0x00d80f34, long * 0x0012e638) line 130 js_Invoke(JSContext * 0x09789990, unsigned int 1, unsigned int 0) line 654 + 26 bytes I'm going to reassign to warren to investigate further. I think we should 1. At a minimum change nsHTTPChannel::OpenInputStream() s.t. it returns an error if it's not going to hand back a valid stream in o_Stream (this'll raise hell with _anyone_ who tries to call it). 2. If we really want to handle this case (I don't see why we wouldn't, if only for symmetry of APIs), then make it s.t. we block until a response is received from the server or some TCP-level timeout occurs. In the meantime, you can (and probably should) do "Refresh(false)" so that the datasource is loaded in the background. You can hook up datasource observers if you need to spy on assertions as they arrive.
Reporter | ||
Comment 4•26 years ago
|
||
The only reason this is being done over HTTP at all is bug 10712. The original idea was to do this with local files. So now the workaround for a crasher is crashing too...
Updated•26 years ago
|
Assignee: warren → gagan
Assignee | ||
Comment 8•25 years ago
|
||
Rick, any hope that you'll be able to look at this for M9? I'd like to go ahead and fix nsHTTPChannel::OpenInputStream() so that it returns NS_ERROR_FAILURE instead of NS_OK if it doesn't actually produce a stream: I have the fix for this in me raedy to go... Index: nsHTTPChannel.cpp =================================================================== RCS file: /cvsroot/mozilla/netwerk/protocol/http/src/nsHTTPChannel.cpp,v retrieving revision 1.47 diff -c -r1.47 nsHTTPChannel.cpp *** nsHTTPChannel.cpp 1999/08/10 04:02:10 1.47 --- nsHTTPChannel.cpp 1999/08/12 18:11:06 *************** *** 188,194 **** if (m_pResponse) return m_pResponse->GetInputStream(o_Stream); NS_ERROR("No response!"); ! return NS_OK; // change to error ? or block till response is set up? #endif // if 0 } --- 188,194 ---- if (m_pResponse) return m_pResponse->GetInputStream(o_Stream); NS_ERROR("No response!"); ! return NS_ERROR_FAILURE; #endif // if 0 }
Comment 9•25 years ago
|
||
hey chris, those changes look fine. You are right that the calls to GetInputStream() and GetOutputStream() on the HTTPChannel should fail until they are correctly implemented. -- rick
Comment 10•25 years ago
|
||
Waterson has a fix/workaround for the assert. But this is basically a dup of bug 10456.
Comment 15•25 years ago
|
||
So chris, do you want me to check the patch into the branch? or will you... -- rick
Assignee | ||
Comment 16•25 years ago
|
||
why don't you patch the branch. i don't have it pulled or anything.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M9 → M10
Comment 17•25 years ago
|
||
I changed nsHTTPChannel::OpenInputStream() to return an NS_ERROR code, but now I'm crashing with the following stack trace... It looks like there is a bad vtbl pointer in mSink since WillBuildModel(...) does *not* call Init(...) I'm crashing in a call to mSink->OpenBody(theNode) which is ending up in RDFContentSinkImpl::Init(...). Of course the arguments passed into Init() are bogus, so we crash... I'm moving this to M10 so we can figure out what's going on... Stack Trace: ============ RDFContentSinkImpl::Init(RDFContentSinkImpl * const 0x02d1a170, nsIURI * 0x0012fc48, nsINameSpaceManager * 0x1005c864 const nsString::`vftable') line 747 CViewSourceHTML::WillBuildModel(CViewSourceHTML * const 0x033c7840, nsString & {...}, int 0x00000001, nsString & {...}, nsIContentSink * 0x02d1a170) line 360 nsParser::WillBuildModel(nsString & {...}, nsIDTD * 0x00000000) line 507 nsParser::ResumeParse(nsIDTD * 0x00000000, int 0x00000000) line 881 + 27 bytes nsParser::OnDataAvailable(nsParser * const 0x02d1a7b4, nsIChannel * 0x02d1eb60, nsISupports * 0x00000000, nsIInputStream * 0x033c6ab0, unsigned int 0x00000000, unsigned int 0x0000066f) line 1168 + 19 bytes nsHTTPResponseListener::OnDataAvailable(nsHTTPResponseListener * const 0x033c2430, nsIChannel * 0x02d1e650, nsISupports * 0x02d1eb60, nsIInputStream * 0x033c6ab0, unsigned int 0x00000000, unsigned int 0x0000066f) line 172 + 47 bytes nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x033c6130) line 350 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x033c6134) line 149 + 12 bytes PL_HandleEvent(PLEvent * 0x033c6134) line 509 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00b0b240) line 470 + 9 bytes _md_EventReceiverProc(HWND__ * 0x01ca03e4, unsigned int 0x0000c0a1, unsigned int 0x00000000, long 0x00b0b240) line 932 + 9 bytes USER32! 77e71268() 00b0b240()
Updated•25 years ago
|
Assignee: rpotts → waterson
Status: ASSIGNED → NEW
Assignee | ||
Updated•25 years ago
|
Assignee | ||
Comment 19•25 years ago
|
||
This looks good. I just tried a test case and am getting a 'not implemented' exception. Which is perfectly reasonable. Marking as fixed. QA: I've added a URL (inside firewall, sorry) that you can hit to verify.
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Updated•25 years ago
|
Resolution: FIXED → ---
Comment 20•25 years ago
|
||
well, chris, your test URL works just dandy, but both of david's URL's listed at the top of this report cause a crash in xpcom.dll on 9/14 windows builds. On the second one, a dialogue comes up with the exception, but a crash follows immediately afterwards. Am I missing something here? If we need a new bug on this (i.e. it's something different) let me know...
Assignee | ||
Updated•25 years ago
|
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Assignee | ||
Comment 21•25 years ago
|
||
I've opened a new bug, 13589. The problem here is table code contained inside xul:boxes. I doubt Karnaze will look at the bugs, because tables inside xul:boxes. *** This bug has been marked as a duplicate of 13589 ***
Assignee | ||
Updated•25 years ago
|
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Assignee | ||
Comment 22•25 years ago
|
||
Let's try that again. Bug 13859. *** This bug has been marked as a duplicate of 13859 ***
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 24•25 years ago
|
||
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
You need to log in
before you can comment on or make changes to this bug.
Description
•