723473 - Crash in nsPluginStreamListenerPeer::SetUpStreamListener @ nsHttpHeaderArray::VisitHeaders with Flashblock

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Scoobidiver (away)]

With combined signatures, it's #9 top crasher in 13.0a1.
It first appeared in 13.0a1/20120201.
The regression window is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3f26b7bee352&tochange=e18c7bc2c28e
It's likely caused by bug 90268.

Signature 	nsHttpHeaderArray::VisitHeaders More Reports Search
UUID	49246059-f467-4af4-9e47-212062120202
Date Processed	2012-02-02 09:11:30
Uptime	906
Last Crash	20.4 minutes before submission
Install Age	8.9 hours since version was first installed.
Install Time	2012-02-02 00:19:08
Product	Firefox
Version	13.0a1
Build ID	20120201031146
Release Channel	nightly
OS	Linux
OS Version	0.0.0 Linux 2.6.32-38-generic #83-Ubuntu SMP Wed Jan 4 11:13:04 UTC 2012 i686
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 15 stepping 11
Crash Reason	SIGSEGV
Crash Address	0x50545454
App Notes 	
OpenGL: NVIDIA Corporation -- GeForce 8400 GS/PCI/SSE2 -- 3.3.0 NVIDIA 280.13 -- texture_from_pixmap
EMCheckCompatibility	True

Frame 	Module 	Signature 	Source
0 	libxul.so 	nsHttpHeaderArray::VisitHeaders 	netwerk/protocol/http/nsHttpHeaderArray.cpp:150
1 	libxul.so 	nsPluginStreamListenerPeer::SetUpStreamListener 	dom/plugins/base/nsPluginStreamListenerPeer.cpp:1184
2 	libxul.so 	nsPluginStreamListenerPeer::OnStartRequest 	dom/plugins/base/nsPluginStreamListenerPeer.cpp:650
3 	libxul.so 	nsObjectLoadingContent::OnStartRequest 	content/base/src/nsObjectLoadingContent.cpp:902
4 	libxul.so 	nsHttpChannel::CallOnStartRequest 	netwerk/protocol/http/nsHttpChannel.cpp:764
5 	libxul.so 	nsHttpChannel::ContinueProcessNormal 	netwerk/protocol/http/nsHttpChannel.cpp:1260
6 	libxul.so 	nsHttpChannel::ProcessNormal 	netwerk/protocol/http/nsHttpChannel.cpp:1197
7 	libxul.so 	nsHttpChannel::ProcessResponse 	netwerk/protocol/http/nsHttpChannel.cpp:1099
8 	libxul.so 	nsHttpChannel::OnStartRequest 	netwerk/protocol/http/nsHttpChannel.cpp:4164
9 	libxul.so 	nsInputStreamPump::OnStateStart 	netwerk/base/src/nsInputStreamPump.cpp:444
10 	libxul.so 	nsInputStreamPump::OnInputStreamReady 	netwerk/base/src/nsInputStreamPump.cpp:399
11 	libxul.so 	nsInputStreamReadyEvent::Run 	xpcom/io/nsStreamUtils.cpp:114
12 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:657
13 	libxul.so 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:245
14 	libxul.so 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:134
15 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:208
16 	libxul.so 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:189
17 	libxul.so 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:220
18 	libxul.so 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3537
19 	firefox 	main 	browser/app/nsBrowserApp.cpp:205
20 	libc-2.11.1.so 	libc-2.11.1.so@0x16bd5 	
21 	firefox 	firefox@0x14d0 	
22 	firefox 	firefox@0x15ff 	
23 	ld-2.11.1.so 	ld-2.11.1.so@0xe02f 	
24 	ld-2.11.1.so 	ld-2.11.1.so@0x1c8f7 

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsHttpHeaderArray%3A%3AVisitHeaders
https://crash-stats.mozilla.com/report/list?signature=nsHttpHeaderArray%3A%3AVisitHeaders%28nsIHttpHeaderVisitor*%29

Comment 1

[Benjamin Smedberg]

The nsPluginStreamListenerPeer is dying at some point before/during the call to nsPluginStreamListenerPeer::SetUpStreamListener. The ownership chain that should keep this alive is:

nsHttpChannel::mListener -> nsObjectLoadingContent*
nsObjectLoadingContent::mFinalListener -> nsPluginStreamListenerPeer*

It's not clear to me whether anything under nsPluginStreamListenerPeer::OnStartRequest could end up clearing either of those two members and causing the destruction of the nsPluginStreamListenerPeer. If there isn't, then we are seeing a refcounting problem which may be the same as bug 723291.

Comment 2

[Scoobidiver (away)]

There's only one comment: "Beats me. I was just waiting for pages to reload after a Nightly update".

Comment 3

[Scoobidiver (away)]

I checked manually crash reports and they have all have Flashblock.

Comment 4

[Josh Aas]

Thanks for figuring that out scoobidiver!

Comment 5

[(not currently active) Ted Mielczarek]

I think I'm hitting this reproducibly on a Huffington Post page. I clicked a link from Facebook and crashed with this signature, and then restored my session (with that tab included) and crashed again immediately.

Comment 6

[(not currently active) Ted Mielczarek]

It was this page, but of course loading it now doesn't seem to crash:
http://www.huffingtonpost.com/2012/02/08/ellen-degeneres-one-million-moms-jc-penney_n_1262623.html

Comment 7

[(not currently active) Ted Mielczarek]

But my session restore seems to reproduce it reliably, so I'm going to spin a local debug build and try to repro in that.

Comment 8

[Benjamin Smedberg]

From Ted's debugging session:

>       xul.dll!nsPluginHost::InstantiateEmbeddedPlugin(const char * aMimeType=0x1fbabba0, nsIURI * aURL=0x1f68b9c0, nsObjectLoadingContent * aContent=0x20bbc7c0, nsPluginInstanceOwner * * aOwner=0x20bbc830)  Line 982 + 0x10 bytes C++
        xul.dll!nsObjectLoadingContent::InstantiatePluginInstance(const char * aMimeType=0x1fbabba0, nsIURI * aURI=0x1f68b9c0)  Line 637 + 0x35 bytes  C++
        xul.dll!nsObjectLoadingContent::SyncStartPluginInstance()  Line 1958 + 0x23 bytes      C++
        xul.dll!nsHTMLPluginObjElementSH::GetPluginInstanceIfSafe(nsIXPConnectWrappedNative * wrapper=0x1fb63b38, JSObject * obj=0x17c22a20, nsNPAPIPluginInstance * * _result=0x0026c7bc)  Line 9601  C++

*aURL is garbage. nsObjectLoadingContent.mURI   {mRawPtr=0x21ed1240 } So the URL changed after the call to nsObjectLoadingContent::InstantiatePluginInstance was called, and we're not kungfudeathgripping it. I'm not sure whether that fix is sufficient, but it's not a bad start.

Comment 9

[Benjamin Smedberg]

Attachment: Add a kungfugrip, rev. 1

Comment 10

[Josh Aas]

Comment on attachment 595500 [details] [diff] [review]
Add a kungfugrip, rev. 1

Review of attachment 595500 [details] [diff] [review]:
-----------------------------------------------------------------

I'd like to land this on m-c now so it'll make the next nightly build.

Comment 11

[Josh Aas]

pushed to mozilla-central

http://hg.mozilla.org/mozilla-central/rev/7c0ba1c98ff7

I realize doing this without a try run is a little risky but this seems pretty safe and I built and tested it myself on Mac OS X. With a try run we'll miss the nightly.

Comment 13

[Johnny Stenback (:jst)]

Given that the ownership of the content type string is the the same as the ownership of mURI, should we create a copy on the stack and pass that to the instantiation code rather than passing mContentType.get() directly as well?

Comment 14

[Johnny Stenback (:jst)]

Attachment: Do the same for mContentType

I.e. something like this?

Comment 15

[Steven Michaud [:smichaud] (Retired)]

Johnny, also take a look at my patch for bug 723520.

Comment 16

[Josh Aas]

Comment on attachment 596147 [details] [diff] [review]
Do the same for mContentType

I think we should do this while we evaluate Steven's other fix.

Comment 17

[Johnny Stenback (:jst)]

The mContentType change landed:

https://hg.mozilla.org/mozilla-central/rev/167b8460ef0d