616861 - crash [@ nsPrefetchNode::OnStopRequest ]

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Scoobidiver (away)]

It is #21 top crasher in Fennec 4.0b3pre for the last week.
It happens at startup (uptime=0).
As the crashing thread is different form the one in bug 598790 for Windows, I file this bug for Android OS.

Signature	nsPrefetchNode::OnStopRequest
UUID	0cce856e-3fa3-4c1e-ba29-270b12101203
Time 	2010-12-03 12:12:07.623183
Uptime	0
Install Age	7850 seconds (2.2 hours) since version was first installed.
Product	Fennec
Version	4.0b3pre
Build ID	20101203021412
Branch	2.0
OS	Linux
OS Version	0.0.0 Linux 2.6.28-omap1 #1 PREEMPT Fri Aug 6 11:50:00 EEST 2010 armv7l
CPU	arm
CPU Info	
Crash Reason	SIGSEGV
Crash Address	0x0
User Comments	

Frame 	Module 	Signature [Expand] 	Source
0 	libxul.so 	nsPrefetchNode::OnStopRequest 	uriloader/prefetch/nsPrefetchService.cpp:338
1 	libxul.so 	mozilla::net::HttpChannelChild::OnStopRequest 	netwerk/protocol/http/HttpChannelChild.cpp:385
2 	libxul.so 	mozilla::net::HttpChannelChild::RecvOnStopRequest 	netwerk/protocol/http/HttpChannelChild.cpp:364
3 	libxul.so 	mozilla::net::PHttpChannelChild::OnMessageReceived 	PHttpChannelChild.cpp:575
4 	libxul.so 	mozilla::dom::PContentChild::OnMessageReceived 	PContentChild.cpp:949
5 	libxul.so 	mozilla::ipc::AsyncChannel::OnDispatchMessage 	ipc/glue/AsyncChannel.cpp:262
6 	libxul.so 	mozilla::ipc::RPCChannel::OnMaybeDequeueOne 	ipc/glue/RPCChannel.cpp:438
7 	libxul.so 	RunnableMethod<mozilla::ipc::RPCChannel,bool ,Tuple0>::Run 	ipc/chromium/src/base/tuple.h:383
8 	libxul.so 	mozilla::ipc::RPCChannel::DequeueTask::Run 	RPCChannel.h:450
9 	libxul.so 	MessageLoop::RunTask 	ipc/chromium/src/base/message_loop.cc:343
10 	libxul.so 	MessageLoop::DeferOrRunPendingTask 	ipc/chromium/src/base/message_loop.cc:351
11 	libxul.so 	MessageLoop::DoWork 	ipc/chromium/src/base/message_loop.cc:451
12 	libxul.so 	mozilla::ipc::DoWorkRunnable::Run 	ipc/glue/MessagePump.cpp:70
13 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:626
14 	libxul.so 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:250
15 	libxul.so 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
16 	libxul.so 	mozilla::ipc::MessagePumpForChildProcess::Run 	ipc/glue/MessagePump.cpp:229
17 	libxul.so 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:219
18 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:202
19 	libxul.so 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:192
20 	libxul.so 	XRE_RunAppShell 	toolkit/xre/nsEmbedFunctions.cpp:631
21 	libxul.so 	mozilla::ipc::MessagePumpForChildProcess::Run 	ipc/glue/MessagePump.cpp:215
22 	libxul.so 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:219
23 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:202
24 	libxul.so 	XRE_InitChildProcess 	toolkit/xre/nsEmbedFunctions.cpp:506
25 	plugin-container 	main 	ipc/app/MozillaRuntimeMain.cpp:80
26 	libc-2.5.so 	libc-2.5.so@0x14973 	
27 	plugin-container 	plugin-container@0x10eb 	
28 	libc-2.5.so 	libc-2.5.so@0x14927 	
29 	libpthread-2.5.so 	libpthread-2.5.so@0x122f 	
30 	ld-2.5.so 	ld-2.5.so@0x134c3 	
31 	libc-2.5.so 	libc-2.5.so@0xb23b 	
32 	ld-2.5.so 	ld-2.5.so@0xd8ab 	
33 	libc-2.5.so 	libc-2.5.so@0xb23b 	
34 	ld-2.5.so 	ld-2.5.so@0xe247 	

More reports at:
http://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=nsPrefetchNode%3A%3AOnStopRequest&version=Fennec%3A4.0b3pre

Comment 1

[Josh Matthews [:jdm]]

Ok, so the only way mChannel can be null in nsPrefetchNode::OnStopRequest is if nsPrefetchNode::CancelChannel has been called.  Now, CancelChannel is only ever called from nsPrefetchService::StopPrefetching, which passes NS_BINDING_ABORTED.  nsPrefetchNode::OnStopRequest checks for a non-failure status code before accessing mChannel, which we would expect to protect against this NPE that we're seeing.  However, if the parent channel has already sent the OnStopRequest message across the wire by the time HttpChannelChild::Cancel is called, we end up in this situation:

>void 
>HttpChannelChild::OnStopRequest(const nsresult& statusCode)
>{
>  ...
>  if (!mCanceled)
>    mStatus = statusCode;
>  ...
>  mListener->OnStopRequest(this, mListenerContext, statusCode);

We only use the status code sent from the parent, instead of the correct mStatus.

Comment 2

[Josh Matthews [:jdm]]

Attachment: Replicate behaviour of nsHttpChannel in regards to failure status codes in OnStopRequest.

Comment 3

[Josh Matthews [:jdm]]

Not a startup crash due to bug 618393.

Comment 4

[Jason Duell]

Comment on attachment 495658 [details] [diff] [review]
Replicate behaviour of nsHttpChannel in regards to failure status codes in OnStopRequest.

Nice catch.

Add comment:

    // honor cancel status: parent may not have gotten it before SendOnStop

>-  if (!mCanceled)
>+  if (!mCanceled && NS_SUCCEEDED(mStatus))
>     mStatus = statusCode;

Comment 5

[Jason Duell]

nom for fennec: very simple fix, fixes crash and correctness of OnStop's status code.

Comment 6

[Brad Lassey [:blassey] (use needinfo?)]

pushed http://hg.mozilla.org/mozilla-central/rev/4f4b4a3222bb