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

RESOLVED FIXED in mozilla13

Status

()

Core
Plug-ins
--
critical
RESOLVED FIXED
6 years ago
5 years ago

People

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

Tracking

({crash, regression})

13 Branch
mozilla13
crash, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
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
(Assignee)

Comment 1

6 years ago
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.
(Reporter)

Comment 2

6 years ago
There's only one comment: "Beats me. I was just waiting for pages to reload after a Nightly update".
(Reporter)

Comment 3

6 years ago
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

Comment 4

6 years ago
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.
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
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.
(Assignee)

Comment 8

6 years ago
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)

Comment 9

6 years ago
Created attachment 595500 [details] [diff] [review]
Add a kungfugrip, rev. 1
Assignee: nobody → benjamin
Status: NEW → ASSIGNED
Attachment #595500 - Flags: review?(joshmoz)

Comment 10

6 years ago
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+

Comment 11

6 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Updated

6 years ago
Duplicate of this bug: 724621
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?
Created attachment 596147 [details] [diff] [review]
Do the same for mContentType

I.e. something like this?
Attachment #596147 - Flags: review?(joshmoz)
Johnny, also take a look at my patch for bug 723520.

Comment 16

5 years ago
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+
The mContentType change landed:

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

Updated

5 years ago
Target Milestone: --- → mozilla13
Blocks: 725279
(Reporter)

Updated

5 years ago
No longer blocks: 725279
Duplicate of this bug: 725279
(Reporter)

Updated

5 years ago
Duplicate of this bug: 724365
(Reporter)

Updated

5 years ago
Blocks: 723520
(Reporter)

Updated

5 years ago
Duplicate of this bug: 723476
(Reporter)

Updated

5 years ago
Duplicate of this bug: 519752
(Reporter)

Updated

5 years ago
Duplicate of this bug: 723291
You need to log in before you can comment on or make changes to this bug.