Closed Bug 723473 Opened 11 years ago Closed 11 years ago

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


(Core Graveyard :: Plug-ins, defect)

13 Branch
Not set


(Not tracked)



(Reporter: scoobidiver, Assigned: benjamin)



(Keywords: crash, regression)

Crash Data


(2 files)

With combined signatures, it's #9 top crasher in 13.0a1.
It first appeared in 13.0a1/20120201.
The regression window is:
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 	nsHttpHeaderArray::VisitHeaders 	netwerk/protocol/http/nsHttpHeaderArray.cpp:150
1 	nsPluginStreamListenerPeer::SetUpStreamListener 	dom/plugins/base/nsPluginStreamListenerPeer.cpp:1184
2 	nsPluginStreamListenerPeer::OnStartRequest 	dom/plugins/base/nsPluginStreamListenerPeer.cpp:650
3 	nsObjectLoadingContent::OnStartRequest 	content/base/src/nsObjectLoadingContent.cpp:902
4 	nsHttpChannel::CallOnStartRequest 	netwerk/protocol/http/nsHttpChannel.cpp:764
5 	nsHttpChannel::ContinueProcessNormal 	netwerk/protocol/http/nsHttpChannel.cpp:1260
6 	nsHttpChannel::ProcessNormal 	netwerk/protocol/http/nsHttpChannel.cpp:1197
7 	nsHttpChannel::ProcessResponse 	netwerk/protocol/http/nsHttpChannel.cpp:1099
8 	nsHttpChannel::OnStartRequest 	netwerk/protocol/http/nsHttpChannel.cpp:4164
9 	nsInputStreamPump::OnStateStart 	netwerk/base/src/nsInputStreamPump.cpp:444
10 	nsInputStreamPump::OnInputStreamReady 	netwerk/base/src/nsInputStreamPump.cpp:399
11 	nsInputStreamReadyEvent::Run 	xpcom/io/nsStreamUtils.cpp:114
12 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:657
13 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:245
14 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:134
15 	MessageLoop::Run 	ipc/chromium/src/base/
16 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:189
17 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:220
18 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3537
19 	firefox 	main 	browser/app/nsBrowserApp.cpp:205
21 	firefox 	firefox@0x14d0 	
22 	firefox 	firefox@0x15ff 	

More reports at:*%29
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.
There's only one comment: "Beats me. I was just waiting for pages to reload after a Nightly update".
I checked manually crash reports and they have all have Flashblock.
Summary: Crash in nsPluginStreamListenerPeer::SetUpStreamListener @ nsHttpHeaderArray::VisitHeaders → Crash in nsPluginStreamListenerPeer::SetUpStreamListener @ nsHttpHeaderArray::VisitHeaders with Flashblock
Thanks for figuring that out scoobidiver!
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.
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.
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.
Assignee: nobody → benjamin
Attachment #595500 - Flags: review?(joshmoz)
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.
Attachment #595500 - Flags: review?(joshmoz) → review+
pushed to mozilla-central

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.
Closed: 11 years ago
Resolution: --- → FIXED
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?
I.e. something like this?
Attachment #596147 - Flags: review?(joshmoz)
Johnny, also take a look at my patch for bug 723520.
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.
Attachment #596147 - Flags: review?(joshmoz) → review+
Target Milestone: --- → mozilla13
No longer blocks: 725279
Blocks: 723520
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.