Closed Bug 254151 Opened 20 years ago Closed 1 year ago

crash [@ nsJARChannel::OnStartRequest] because AsyncRead is not the last thing called in AsyncOpen

Categories

(Core :: Networking, defect, P5)

x86
Windows XP
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: timeless, Unassigned)

References

Details

(Keywords: crash, Whiteboard: [necko-would-take])

Crash Data

Attachments

(1 file)

necko.dll!nsJARChannel::OnStartRequest(nsIRequest * req=0x05d28840,
nsISupports * ctx=0x00000000)  Line 673 + 0xb	C++
 	necko.dll!nsInputStreamPump::OnStateStart()  Line 383	C++
 	necko.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream *
stream=0x05d28950)  Line 345	C++
 	xpcom.dll!nsInputStreamReadyEvent::EventHandler(PLEvent * plevent=0x05d29134)
 Line 119	C++
 	xpcom.dll!PL_HandleEvent(PLEvent * self=0x05d29134)  Line 693	C
 	xpcom.dll!PL_ProcessPendingEvents(PLEventQueue * self=0x00f69568)  Line 628	C
 	xpcom.dll!nsEventQueueImpl::ProcessPendingEvents()  Line 395	C++
 	xpcom.dll!nsEventQueueImpl::ProcessPendingEvents()  Line 404	C++
 	xpcom.dll!nsEventQueueImpl::ProcessPendingEvents()  Line 404	C++
 	gkwidget.dll!nsWindow::DispatchPendingEvents()  Line 3808	C++
 	gkwidget.dll!nsWindow::ProcessMessage(unsigned int msg=0x00000101, unsigned
int wParam=0x0000000d, long lParam=0xc01c0001, long * aRetValue=0x0012c58c) 
Line 4184	C++
 	gkwidget.dll!nsWindow::WindowProc(HWND__ * hWnd=0x009506da, unsigned int
msg=0x00000101, unsigned int wParam=0x0000000d, long lParam=0x03fa600c)  Line
1379 + 0x10	C++
 	user32.dll!77d43a50() 	
 	user32.dll!77d43b1f() 	
 	user32.dll!GetMessageW()  + 0x125	
 	user32.dll!DispatchMessageW()  + 0xb	
 	xpcom.dll!XPTC_InvokeByIndex(nsISupports * that=0x00f84510, unsigned int
methodIndex=0x00000031, unsigned int paramCount=0x00000002, nsXPTCVariant *
params=0x0012c734)  Line 102	C++
 	xpc3250.dll!XPCWrappedNative::CallMethod(XPCCallContext & ccx={...},
XPCWrappedNative::CallMode mode=CALL_METHOD)  Line 2028 + 0x15	C++
 	xpc3250.dll!XPC_WN_CallMethod(JSContext * cx=0x01680c40, JSObject *
obj=0x044fa468, unsigned int argc=0x00000001, long * argv=0x0447fac4, long *
vp=0x0012c9a4)  Line 1287 + 0xa	C++
 	js3250.dll!js_Invoke(JSContext * cx=0xa1c3003b, unsigned int argc=0x003b1cb8,
unsigned int flags=0x0e75c085)  Line 1281 + 0x11	C
 	js3250.dll!js_Interpret(JSContext * cx=0x003b1cb8, long * result=0x0e75c085) 
Line 3376	C
 	js3250.dll!js_Invoke(JSContext * cx=0xa1c3003b, unsigned int argc=0x003b1cb8,
unsigned int flags=0x0e75c085)  Line 1301 + 0xa	C
 	xpc3250.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS *
wrapper=0x1cb8a159, unsigned short methodIndex=0x003b, const nsXPTMethodInfo *
info=0x003b1cb8, nsXPTCMiniVariant * nativeParams=0x0e75c085)  Line 1410 + 0x10	C++
 	xpc3250.dll!nsXPCWrappedJS::CallMethod(unsigned short methodIndex=0x0003,
const nsXPTMethodInfo * info=0x041956c8, nsXPTCMiniVariant * params=0x0012cdbc)
 Line 450	C++
 	xpcom.dll!PrepareAndDispatch(nsXPTCStubBase * self=0x0468ded8, unsigned int
methodIndex=0x00000003, unsigned int * args=0x0012ce80, unsigned int *
stackBytesToPop=0x0012ce70)  Line 117 + 0x1a	C++
 	xpcom.dll!SharedStub()  Line 147	C++
 	jsd3250.dll!jsds_ExecutionHookProc(JSDContext * jsdc=0x00f84598,
JSDThreadState * jsdthreadstate=0x05d353e8, unsigned int type=0x00000002, void *
callerdata=0x00000000, long * rval=0x0012cf0c)  Line 683	C++
 	jsd3250.dll!jsd_CallExecutionHook(JSDContext * jsdc=0x00f84598, JSContext *
cx=0x01680c40, unsigned int type=0x00000002, unsigned int (JSDContext *,
JSDThreadState *, unsigned int, void *, long *)* hook=0x01491a85, void *
hookData=0x00000000, long * rval=0x0012cf0c)  Line 178	C
 	jsd3250.dll!jsd_DebugErrorHook(JSContext * cx=0x01680c40, const char *
message=0x0390a490, JSErrorReport * report=0x0012cf54, void *
closure=0x00000000)  Line 365 + 0x16	C
 	js3250.dll!js_ReportErrorAgain(JSContext * cx=0x01680c40, const char *
message=0x05d332b0, JSErrorReport * reportp=0x0012cf54)  Line 669 + 0x11	C
 	js3250.dll!ReportError(JSContext * cx=0x05d282b8, const char *
message=0x05d332b0, JSErrorReport * reportp=0x80000000)  Line 335 + 0xb	C
 	js3250.dll!js_ReportErrorNumberVA(JSContext * cx=0x01680c40, unsigned int
flags=0x05d332b0, const JSErrorFormatString * (void *, const char *, const
unsigned int)* callback=0x01051d2f, void * userRef=0x00000000, const unsigned
int errorNumber=0x000000a2, int charArgs=0x00000001, char * ap=0x0012cfc0) 
Line 632	C
 	js3250.dll!JS_ReportErrorFlagsAndNumber(JSContext * cx=0x01680c40, unsigned
int flags=0x00000005, const JSErrorFormatString * (void *, const char *, const
unsigned int)* errorCallback=0x01051d2f, void * userRef=0x00000000, const
unsigned int errorNumber=0x000000a2, ...)  Line 4021 + 0x1a	C
 	js3250.dll!js_GetProperty(JSContext * cx=0x01680c40, JSObject *
obj=0x05870790, long id=0x02ccd140, long * vp=0x0012d13c)  Line 2770 + 0x22	C
 	js3250.dll!js_Interpret(JSContext * cx=0x003b1cb8, long * result=0x0e75c085) 
Line 3202 + 0x354	C
 	js3250.dll!js_Invoke(JSContext * cx=0xa1c3003b, unsigned int argc=0x003b1cb8,
unsigned int flags=0x0e75c085)  Line 1301 + 0xa	C
 	js3250.dll!js_Interpret(JSContext * cx=0x003b1cb8, long * result=0x0e75c085) 
Line 2949	C
 	js3250.dll!js_Invoke(JSContext * cx=0xa1c3003b, unsigned int argc=0x003b1cb8,
unsigned int flags=0x0e75c085)  Line 1301 + 0xa	C
 	xpc3250.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS *
wrapper=0x1cb8a159, unsigned short methodIndex=0x003b, const nsXPTMethodInfo *
info=0x003b1cb8, nsXPTCMiniVariant * nativeParams=0x0e75c085)  Line 1410 + 0x10	C++
 	xpc3250.dll!nsXPCWrappedJS::CallMethod(unsigned short methodIndex=0x0003,
const nsXPTMethodInfo * info=0x03c35e88, nsXPTCMiniVariant * params=0x0012d598)
 Line 450	C++
 	xpcom.dll!PrepareAndDispatch(nsXPTCStubBase * self=0x05ab2398, unsigned int
methodIndex=0x00000003, unsigned int * args=0x0012d65c, unsigned int *
stackBytesToPop=0x0012d64c)  Line 117 + 0x1a	C++
 	xpcom.dll!SharedStub()  Line 147	C++
 	appcomps.dll!nsBrowserStatusFilter::OnStateChange(nsIWebProgress *
aWebProgress=0x03bd1afc, nsIRequest * aRequest=0x05d282b0, unsigned int
aStateFlags=0x00070001, unsigned int aStatus=0x00000000)  Line 175 + 0x18	C++
 	docshell.dll!nsDocLoaderImpl::FireOnStateChange(nsIWebProgress *
aProgress=0x03bd1afc, nsIRequest * aRequest=0x05d282b0, int
aStateFlags=0x00070001, unsigned int aStatus=0x00000000)  Line 1240	C++
 	docshell.dll!nsDocLoaderImpl::doStartDocumentLoad(nsIRequest *
request=0x05d282b0)  Line 801	C++
 	docshell.dll!nsDocLoaderImpl::OnStartRequest(nsIRequest * request=0x00000001,
nsISupports * aCtxt=0x00000000)  Line 547	C++
>	necko.dll!nsLoadGroup::AddRequest(nsIRequest * request=0x00000000, nsISupports
* ctxt=0x00000000)  Line 621	C++
 	necko.dll!nsJARChannel::AsyncOpen(nsIStreamListener * listener=0x05d27d70,
nsISupports * ctx=0x00000000)  Line 621	C++
 	docshell.dll!nsDocumentOpenInfo::Open(nsIChannel * aChannel=0x05d282b0) 
Line 226	C++
 	docshell.dll!nsURILoader::OpenURI(nsIChannel * channel=0x05d27d70, int
aIsContentPreferred=0x00000000, nsIInterfaceRequestor *
aWindowContext=0x03bc6938)  Line 823 + 0x10	C++
 	docshell.dll!nsDocShell::DoChannelLoad(nsIChannel * aChannel=0x00000003,
nsIURILoader * aURILoader=0x0161f300)  Line 5888 + 0x1b	C++
 	docshell.dll!nsDocShell::DoURILoad(nsIURI * aURI=0x05d27af0, nsIURI *
aReferrerURI=0x00000000, nsISupports * aOwner=0x04b56308, const char *
aTypeHint=0x00000000, nsIInputStream * aPostData=0x00000000, nsIInputStream *
aHeadersData=0x00000000, int firstParty=0x00000001, nsIDocShell * *
aDocShell=0x00000000, nsIRequest * * aRequest=0x00000000)  Line 5667	C++
 	docshell.dll!nsDocShell::InternalLoad(nsIURI * aURI=0x05d27af0, nsIURI *
aReferrer=0x00000000, nsISupports * aOwner=0x00000000, int
aInheritOwner=0x00000000, const unsigned short * aWindowTarget=0x0520b450, const
char * aTypeHint=0x00000000, nsIInputStream * aPostData=0x00000000,
nsIInputStream * aHeadersData=0x00000000, unsigned int aLoadType=0x00000001,
nsISHEntry * aSHEntry=0x00000000, int firstParty=0x00000001, nsIDocShell * *
aDocShell=0x00000000, nsIRequest * * aRequest=0x00000000)  Line 5453 + 0x25	C++
 	docshell.dll!nsDocShell::LoadURI(nsIURI * aURI=0x1cb8a159, nsIDocShellLoadInfo
* aLoadInfo=0xa1c3003b, unsigned int aLoadFlags=0x003b1cb8, int
firstParty=0x0e75c085)  Line 774	C++
 	docshell.dll!nsDocShell::LoadURI(const unsigned short * aURI=0x59fffa76,
unsigned int aLoadFlags=0x1cb8a159, nsIURI * aReferringURI=0xa1c3003b,
nsIInputStream * aPostStream=0x003b1cb8, nsIInputStream *
aHeaderStream=0x0e75c085)  Line 2588	C++
 	xpcom.dll!XPTC_InvokeByIndex(nsISupports * that=0x03bc6920, unsigned int
methodIndex=0x00000008, unsigned int paramCount=0x00000005, nsXPTCVariant *
params=0x0012dd3c)  Line 102	C++

Contributing factors:
there's a patch to docloader, there's a js observer which listens to loads
(possibly buggy), venkman was running.

venkman/jsd pushed a nested event queue and allowed events to be processed,
which led to the crash.

biesi suggests reordering the addrequest/asyncread calls
another possibility would be to make nsLoadGroup notify the groupObserver
asynchronously
Attachment #155090 - Flags: superreview?(darin)
Attachment #155090 - Flags: review?(cbiesinger)
Comment on attachment 155090 [details] [diff] [review]
reorder addrequest

hmm, so the reason this is required is because your loadgroup's observer
eventually processes events, which means the jarchannel will get an
onstartrequest before asyncopen returned.


I am not sure we want to support that, really...
no, we don't want to support that.  the problem is with the way nested event
queues work.  when a nested event queue is popped, it processes pending events
on itself as well as on its elder queue.

necko needs a way to guarantee that its events will fire asynchronously to the
rest of the execution stack.  i.e., necko events must never be fired when necko
is already on the stack.
Comment on attachment 155090 [details] [diff] [review]
reorder addrequest

minusing... this is only a bandaid that doesn't address the real problem.  we
don't want to go down this road.
Attachment #155090 - Flags: superreview?(darin) → superreview-
making the calls to AddRequest/RemoveRequest trigger asynchronous groupObserver
calls is maybe the right solution.  the concern there is how it may impact other
things... for example, it might be possible for another request to get added to
the loadgroup while a PLEvent is in the queue waiting to call the
groupObserver's OnStopRequest method.  does that mean that we need that PLEvent
to check the state of the loadGroup before calling OnStopRequest?  how do we
know that the loadGroup isn't being used for a new page load?  (i.e., the user
could have entered a new URL in the URL bar while the load was finishing.)  you
see... such a simple change could be fraught with painful regressions :-/
Attachment #155090 - Flags: review?(cbiesinger) → review-
re comment 4, darin: erm, look at this stack, you're asking for the app to die when venkman starts in 
response to any break like this.

as to load groups, i don't trust them at all, their contracts are unclear and i can change them at any 
time.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5
Crash Signature: [@ nsJARChannel::OnStartRequest]
This is very low volume but it does exist. We have 4 crashes on 7.0.1 in the past 4 weeks. Most of the crashes happen in 3.1, 3.5 and 3.6. Even then, it's pretty low volume.
Whiteboard: [necko-would-take]

The bug assignee didn't login in Bugzilla in the last months and this bug has severity 'critical'.
:dragana, could you have a look please?
For more information, please visit auto_nag documentation.

Assignee: timeless → nobody
Flags: needinfo?(dd.mozilla)
Flags: needinfo?(dd.mozilla)

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Severity: critical → S3

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: