Closed Bug 616861 Opened 15 years ago Closed 15 years ago

crash [@ nsPrefetchNode::OnStopRequest ]

Categories

(Core :: Networking: HTTP, defect)

ARM
Android
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
fennec 2.0b4+ ---

People

(Reporter: scoobidiver, Assigned: jdm)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

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
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.
Assignee: nobody → josh
Attachment #495658 - Flags: review?(jduell.mcbugs)
Not a startup crash due to bug 618393.
Summary: startup crash [@ nsPrefetchNode::OnStopRequest ] → crash [@ nsPrefetchNode::OnStopRequest ]
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;
Attachment #495658 - Flags: review?(jduell.mcbugs)
Attachment #495658 - Flags: review+
Attachment #495658 - Flags: approval2.0?
nom for fennec: very simple fix, fixes crash and correctness of OnStop's status code.
tracking-fennec: --- → ?
tracking-fennec: ? → 2.0-
Attachment #495658 - Flags: approval2.0? → approval2.0+
tracking-fennec: 2.0- → 2.0b4+
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Crash Signature: [@ nsPrefetchNode::OnStopRequest ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: