Crash @ mozilla::net::HttpChannelParent::RecvMarkOfflineCacheEntryAsForeign

RESOLVED FIXED in mozilla15



Networking: HTTP
6 years ago
5 years ago


(Reporter: Scoobidiver (away), Assigned: mayhemer)


({crash, regression, topcrash})

9 Branch
crash, regression, topcrash
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [mobile-crash], crash signature)


(1 attachment, 1 obsolete attachment)



6 years ago
It's #5 top crasher in Fennec 9.0.

Signature 	mozilla::net::HttpChannelParent::RecvMarkOfflineCacheEntryAsForeign More Reports Search
UUID	5c4b82ed-1f85-4823-b897-a07b52120104
Date Processed	2012-01-04 15:38:12.278705
Uptime	183
Last Crash	more than 3 months before submission
Install Age	1.2 weeks since version was first installed.
Install Time	2011-12-27 19:49:06
Product	Fennec
Version	9.0
Build ID	20111216135618
Release Channel	release
OS	Linux
OS Version	0.0.0 Linux #1 PREEMPT Sat Aug 20 10:40:49 IST 2011 armv7l
Build Architecture	arm
Build Architecture Info	
Crash Reason	SIGSEGV
Crash Address	0x0
App Notes 	
motorola DROIDX

Frame 	Module 	Signature [Expand] 	Source
0 	mozilla::net::HttpChannelParent::RecvMarkOfflineCacheEntryAsForeign 	netwerk/protocol/http/HttpChannelParent.cpp:365
1 	mozilla::net::PHttpChannelParent::OnMessageReceived 	obj-firefox/ipc/ipdl/PHttpChannelParent.cpp:659
2 	mozilla::dom::PContentParent::OnMessageReceived 	obj-firefox/ipc/ipdl/PContentParent.cpp:752
3 	mozilla::ipc::AsyncChannel::OnDispatchMessage 	ipc/glue/AsyncChannel.cpp:294
4 	mozilla::ipc::RPCChannel::OnMaybeDequeueOne 	ipc/glue/RPCChannel.cpp:433
5 	RunnableMethod<mozilla::ipc::RPCChannel, bool , Tuple0>::Run 	ipc/chromium/src/base/tuple.h:383
6 	mozilla::ipc::RPCChannel::DequeueTask::Run 	RPCChannel.h:464
7 	MessageLoop::RunTask 	ipc/chromium/src/base/
8 	MessageLoop::DeferOrRunPendingTask 	ipc/chromium/src/base/
9 	MessageLoop::DoWork 	ipc/chromium/src/base/
10 	mozilla::ipc::DoWorkRunnable::Run 	ipc/glue/MessagePump.cpp:70
11 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:631
12 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:245
13 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
14 	MessageLoop::RunInternal 	ipc/chromium/src/base/
15 	MessageLoop::Run 	ipc/chromium/src/base/
16 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:189
17 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:228

Comment 1

6 years ago
This can happen only for a top-level document loading channels being satisfied from offline cache.  mChannel had already been nullified from the parent channel.

Marking a cache entry as foreign is triggered from content sink (early) during parsing of the document content on the content process.  It prevents load of the document from the offline cache on next load.  The document is reloaded after that marking.

Problem is that we will simply loop when the cache entry is not marked as foreign because on the next load attempt the conditions leading to mark/reload action will pass again.

We cannot hold the cache entry or the channel on the chrome process to not hold on loads of the same page in other tabs.  We artificially throw the reference to the channel and the cache entry away after the document had been delivered to the content process.

We could delay this artificial release until/after "SetMark" happened to be called when loading a top level doc from offline cache.
Assignee: nobody → honzab.moz

Comment 2

6 years ago
It's still #5 top browser crasher in XUL Fennec 10.0.3esr (340,000 ADU).
The Aurora (800 ADU) and Nightly (500 ADU) population seems unaffected in Native Fennec.

Comment 3

5 years ago
Created attachment 620769 [details] [diff] [review]

- simple patch
- leaves the cleanup logic intact
- to mark an entry offline HttpChannelParent is using a class, provided by nsHttpChannel, having a method MarkForeign()
- the class just keeps what's necessary to perform the op: app cache instance and the key
Attachment #620769 - Flags: review?(jduell.mcbugs)
Comment on attachment 620769 [details] [diff] [review]

Review of attachment 620769 [details] [diff] [review]:

Looks good.

> The Aurora (800 ADU) and Nightly (500 ADU) population seems unaffected in Native Fennec.

Yes, because they don't use e10s.  We'll need this for B2G, but don't need to backport anywhere.

::: netwerk/protocol/http/nsHttpChannel.h
@@ +160,5 @@
>          mRequestHead.SetHeader(nsHttp::Referer, spec);
>          return NS_OK;
>      }
> +    class OfflineCacheEntryAsForeignMarker {

Add comment:

// This allows cache entry to be marked as foreign even after channel itself
// is gone.  Needed for e10s (see HttpChannelParent::RecvDocumentChannelCleanup)
Attachment #620769 - Flags: review?(jduell.mcbugs) → review+

Comment 5

5 years ago
Comment on attachment 620769 [details] [diff] [review]
Attachment #620769 - Flags: checkin+
Backed out, it's burning all the platforms.

Comment 7

5 years ago
(In reply to Geoff Lankow (:darktrojan) from comment #6)
> Backed out, it's burning all the platforms.

Except Windows I assume, since it is too much benevolent...  Thanks for the backout.


5 years ago
Attachment #620769 - Flags: checkin+

Comment 8

5 years ago
Created attachment 621701 [details] [diff] [review]
v1.1 (as landed)
Attachment #620769 - Attachment is obsolete: true
Attachment #621701 - Flags: review+
Attachment #621701 - Flags: checkin+
Original landing and backout:

Also, should this have a test?
Flags: in-testsuite?
Target Milestone: --- → mozilla15
Last Resolved: 5 years ago
Resolution: --- → FIXED

Comment 11

5 years ago
(In reply to Ryan VanderMeulen from comment #9)
> Also, should this have a test?

There is a test.  Just don't run on e10s (fennec).  I'm able to make fennec crash w/o this fix quit easily.
Flags: in-testsuite? → in-testsuite-
You need to log in before you can comment on or make changes to this bug.