Last Comment Bug 723473 - Crash in nsPluginStreamListenerPeer::SetUpStreamListener @ nsHttpHeaderArray::VisitHeaders with Flashblock
: Crash in nsPluginStreamListenerPeer::SetUpStreamListener @ nsHttpHeaderArray:...
: crash, regression
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: 13 Branch
: All All
-- critical (vote)
: mozilla13
Assigned To: Benjamin Smedberg [:bsmedberg]
: Benjamin Smedberg [:bsmedberg]
: 519752 723291 723476 724365 724621 725279 (view as bug list)
Depends on:
Blocks: 723520 90268
  Show dependency treegraph
Reported: 2012-02-02 05:02 PST by Scoobidiver (away)
Modified: 2012-02-15 14:16 PST (History)
13 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Add a kungfugrip, rev. 1 (1.16 KB, patch)
2012-02-08 13:05 PST, Benjamin Smedberg [:bsmedberg]
jaas: review+
Details | Diff | Splinter Review
Do the same for mContentType (1.19 KB, patch)
2012-02-10 12:44 PST, Johnny Stenback (:jst,
jaas: review+
Details | Diff | Splinter Review

Description User image Scoobidiver (away) 2012-02-02 05:02:01 PST
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
Comment 1 User image Benjamin Smedberg [:bsmedberg] 2012-02-02 07:23:37 PST
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 User image Scoobidiver (away) 2012-02-02 09:20:26 PST
There's only one comment: "Beats me. I was just waiting for pages to reload after a Nightly update".
Comment 3 User image Scoobidiver (away) 2012-02-02 23:47:39 PST
I checked manually crash reports and they have all have Flashblock.
Comment 4 User image Josh Aas 2012-02-03 00:12:03 PST
Thanks for figuring that out scoobidiver!
Comment 5 User image Ted Mielczarek [:ted.mielczarek] 2012-02-08 11:23:39 PST
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 User image Ted Mielczarek [:ted.mielczarek] 2012-02-08 11:25:07 PST
It was this page, but of course loading it now doesn't seem to crash:
Comment 7 User image Ted Mielczarek [:ted.mielczarek] 2012-02-08 11:39:11 PST
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 User image Benjamin Smedberg [:bsmedberg] 2012-02-08 12:44:34 PST
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 User image Benjamin Smedberg [:bsmedberg] 2012-02-08 13:05:56 PST
Created attachment 595500 [details] [diff] [review]
Add a kungfugrip, rev. 1
Comment 10 User image Josh Aas 2012-02-08 15:08:44 PST
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 User image Josh Aas 2012-02-08 15:17:22 PST
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.
Comment 12 User image Benjamin Smedberg [:bsmedberg] 2012-02-08 16:49:53 PST
*** Bug 724621 has been marked as a duplicate of this bug. ***
Comment 13 User image Johnny Stenback (:jst, 2012-02-10 12:42:53 PST
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 User image Johnny Stenback (:jst, 2012-02-10 12:44:19 PST
Created attachment 596147 [details] [diff] [review]
Do the same for mContentType

I.e. something like this?
Comment 15 User image Steven Michaud [:smichaud] (Retired) 2012-02-10 13:36:04 PST
Johnny, also take a look at my patch for bug 723520.
Comment 16 User image Josh Aas 2012-02-13 12:11:06 PST
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 User image Johnny Stenback (:jst, 2012-02-13 13:29:11 PST
The mContentType change landed:
Comment 18 User image Scoobidiver (away) 2012-02-14 05:31:48 PST
*** Bug 725279 has been marked as a duplicate of this bug. ***
Comment 19 User image Scoobidiver (away) 2012-02-14 05:35:07 PST
*** Bug 724365 has been marked as a duplicate of this bug. ***
Comment 20 User image Scoobidiver (away) 2012-02-14 05:42:10 PST
*** Bug 723476 has been marked as a duplicate of this bug. ***
Comment 21 User image Scoobidiver (away) 2012-02-14 05:57:33 PST
*** Bug 519752 has been marked as a duplicate of this bug. ***
Comment 22 User image Scoobidiver (away) 2012-02-15 14:16:08 PST
*** Bug 723291 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.