Closed
Bug 616861
Opened 15 years ago
Closed 15 years ago
crash [@ nsPrefetchNode::OnStopRequest ]
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
fennec | 2.0b4+ | --- |
People
(Reporter: scoobidiver, Assigned: jdm)
References
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
1.77 KB,
patch
|
jduell.mcbugs
:
review+
blassey
:
approval2.0+
|
Details | Diff | Splinter Review |
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
Assignee | ||
Comment 1•15 years ago
|
||
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 | ||
Updated•15 years ago
|
Assignee: nobody → josh
Assignee | ||
Comment 2•15 years ago
|
||
Assignee | ||
Updated•15 years ago
|
Attachment #495658 -
Flags: review?(jduell.mcbugs)
Assignee | ||
Comment 3•15 years ago
|
||
Not a startup crash due to bug 618393.
Summary: startup crash [@ nsPrefetchNode::OnStopRequest ] → crash [@ nsPrefetchNode::OnStopRequest ]
Comment 4•15 years ago
|
||
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?
Comment 5•15 years ago
|
||
nom for fennec: very simple fix, fixes crash and correctness of OnStop's status code.
tracking-fennec: --- → ?
Updated•15 years ago
|
tracking-fennec: ? → 2.0-
Updated•15 years ago
|
Attachment #495658 -
Flags: approval2.0? → approval2.0+
Updated•15 years ago
|
tracking-fennec: 2.0- → 2.0b4+
Comment 6•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
Crash Signature: [@ nsPrefetchNode::OnStopRequest ]
You need to log in
before you can comment on or make changes to this bug.
Description
•