Closed Bug 11112 Opened 25 years ago Closed 25 years ago

Crash calling blocking read on nsHTTPChannel

Categories

(Core :: Networking, defect, P1)

Product:
Core
Component:
Networking
Platform:
Other
Other
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 13859

People

(Reporter: dbaron, Assigned: waterson)

References

(
URL
)

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.
Assignee: slamm → waterson
Component: Sidebar → RDF
Summary: Crash on load of customized sidebar panels. → Crash on opening RDF datasource
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.
Status: NEW → ASSIGNED
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
Summary: Crash synchronously opening an RDF/XML datasource from a remote location → Crash calling blocking read on nsHTTPChannel
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.
Blocks: 9730
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...
Assignee: warren → gagan
Gagan should investigate.
*** Bug 11538 has been marked as a duplicate of this bug. ***
rpotts for comments.
Assignee: gagan → rpotts
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

  }
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
Waterson has a fix/workaround for the assert. But this is basically a dup of
bug 10456.
hey chris,

did you check your fixes in for this?

-- rick
No, I never checked it in.
Can this fix be checked into M9 branch?  low risk?
Yes, this fix can and should be checked in to the M9 branch.
So chris,
do you want me to check the patch into the branch? or will you...

-- rick
why don't you patch the branch. i don't have it pulled or anything.
Status: NEW → ASSIGNED
Target Milestone: M9 → M10
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()
Assignee: rpotts → waterson
Status: ASSIGNED → NEW
hey chris,

Any idea what's going on here??
URL: http://btek/bugs/11112.html
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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...
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
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 ***
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Let's try that again. Bug 13859.

*** This bug has been marked as a duplicate of 13859 ***
Status: RESOLVED → VERIFIED
okay dokey
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.