Closed Bug 649795 Opened 13 years ago Closed 13 years ago

crash [@ nsPluginStreamListenerPeer::ServeStreamAsFile(nsIRequest*, nsISupports*)]


(Core Graveyard :: Plug-ins, defect)

5 Branch
Not set


(firefox5+ fixed)

Tracking Status
firefox5 + fixed


(Reporter: charles.fenwick, Assigned: jst)


(Keywords: crash, regression)

Crash Data


(1 file)

This bug was filed from the Socorro interface and is 
report bp-2a31b196-3916-4f92-965f-1f5e72110413 .
0 	xul.dll 	nsPluginStreamListenerPeer::ServeStreamAsFile 	modules/plugin/base/src/nsPluginStreamListenerPeer.cpp:877
1 	xul.dll 	nsPluginByteRangeStreamListener::OnStartRequest 	modules/plugin/base/src/nsPluginStreamListenerPeer.cpp:178
2 	xul.dll 	nsHttpChannel::CallOnStartRequest 	netwerk/protocol/http/nsHttpChannel.cpp:773
3 	xul.dll 	nsHttpChannel::ContinueProcessNormal 	netwerk/protocol/http/nsHttpChannel.cpp:1224
4 	xul.dll 	nsHttpChannel::ProcessNormal 	netwerk/protocol/http/nsHttpChannel.cpp:1161
5 	xul.dll 	nsHttpChannel::ProcessResponse 	netwerk/protocol/http/nsHttpChannel.cpp:1048
6 	xul.dll 	nsHttpChannel::OnStartRequest 	netwerk/protocol/http/nsHttpChannel.cpp:3959
7 	xul.dll 	nsInputStreamPump::OnStateStart 	netwerk/base/src/nsInputStreamPump.cpp:441
8 	xul.dll 	nsInputStreamPump::OnInputStreamReady 	netwerk/base/src/nsInputStreamPump.cpp:397
9 	xul.dll 	nsInputStreamReadyEvent::Run 	xpcom/io/nsStreamUtils.cpp:114
10 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:618
11 	xul.dll 	TimerThread::RemoveTimer 	xpcom/threads/TimerThread.cpp:417
12 	xul.dll 	MessageLoop::RunInternal 	ipc/chromium/src/base/
13 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/
14 	mozcrt19.dll 	_VEC_memzero 	
15 	xul.dll 	xul.dll@0x37112f 	
16 	firefox.exe 	firefox.exe@0x1bb7 	
17 	ntdll.dll 	WinSqmSetIfMaxDWORD 	
18 	ntdll.dll 	_RtlUserThreadStart 	
19 	firefox.exe 	firefox.exe@0x186f 	
20 	firefox.exe 	firefox.exe@0x186f

Step to reproduce:

1. Attempt to open a pdf file, e.g.

First crash logged in nightly Apr 12, 2011 14:16. ~40 crashes logged since then.
OS: Windows NT → Windows 7
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins shows that this is happening across 2.1a1pre, 5.0a2 and 6.0a1, which is probably expected, given the recent uplift to Aurora and this being present before that. Windows versions affected seem to be all, XP as well as Vista as well as 7.

The few comments all talk about opening a PDF, as comment #0 implies as well.
Although the ADUs are still low, this is the top browser crash on Aurora right now. No idea if it's connected to a regression. I will try and get some more data. Nominating for tracking for now.

This is also the top browser crash on the trunk.
Josh, bsmbedberg, this seems to be the nr 1 top crash, can you guys investigate here?
Timing of the patch for bug 617539 landing (changeset 67851:3aebb305dee5) and the appearance of this crash seems to suggest the two are related.
I am perfectly fine with backing out just, since I really didn't mean for it to land anyway. We'll have to back out bug 651177 also.
Also happens with Linux, see b5ba6da8-5750-45f5-b95e-0d7202110420. Aurora crashes every time I try to open
OS: Windows 7 → All
Hardware: x86 → All
There were several other changes in FF5 timeframe which affected cache behavior: I really want to make sure the regression range is correct here before doing backouts which may be incorrect.
Keywords: qawanted
Downloaded and tested a few nightlies on a fresh profile.

Apr 10 Built from no crash
Apr 11 Built from no crash
Apr 12 Built from crash

For entertainment, tested today's nightly 
Built from

and unsurprisingly it crashed on the example link.
OS: All → Windows 7
Hardware: All → x86
OS: Windows 7 → All
Hardware: x86 → All
Hello Charles: I have tried a few times on Win XP and not been able to reproduce the crash. Which version of Adobe are you using?

I mistakenly assumed I was running the most current version of Adobe, but instead I merely had the most recent 9.x (, specifically). 

Upgraded to Adobe 10.0.1 and re-tested. Result: No crash.
Charles: Thanks for the update. I can reproduce the crash using Version: and Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110426 Firefox/6.0a1 and I can confirm the regression range in Cmment 8 is accurate.
Attached patch Likely fix.Splinter Review
It's not clear to me why we initially used mOwner here instead of owner, which we know here is non-null. It's also not clear to me why mOwner is null here, but it seems that is only ever set if InitializeEmbedded() is called, not if we call Initialize() or InitializeFullPage().
Attachment #528372 - Flags: review?
Comment on attachment 528372 [details] [diff] [review]
Likely fix.

I'm not sure this is right (but I'm not sure it's wrong either). The original change was here:

in this case, `owner` was a QI from mOwner, not the owner from above. In which case, returning to the original behavior would just null-check mOwner and use it.
The original use of mOwner came in here:

where we'd call SetWindow() whether mOwner was set or not, so I'm arguing that my change is "correct", whatever that means here.
Comment on attachment 528372 [details] [diff] [review]
Likely fix.

Don't know whether you meant for me to review this, but I'll accept your explanation with fingers crossed!
Attachment #528372 - Flags: review? → review+
This will help fix a top crash on the trunk and Aurora. Can someone check it in?
jst went on vacation, so I guess I'll steal it.
Assignee: nobody → benjamin
Landed on mozilla-central:
Closed: 13 years ago
Resolution: --- → FIXED
Comment on attachment 528372 [details] [diff] [review]
Likely fix.

It looks like the crash went away in today's crash data (so far, at least), so requesting approval for Aurora.

(We *might* want to wait a little bit, but I'm not sure.)
Attachment #528372 - Flags: approval-mozilla-aurora?
I checked crash stats today, and other than one crash on the trunk with build id 20110503030636, there are no further crashes. So I think this is good to go on Aurora.
Tested this out on my other computer that still has Adobe 9.x (to make sure I could see the crash pre-fix). As expected, pre-fix nightly (May 2) crashed on the example link while today's did not.  Have not noted any side-effects.  As Marcia stated, the only crashes observed today with this signature were from the last pre-fix nightly,  so it seems this crash has been eradicated from nightlies. Just need to get the fix on Aurora.
Attachment #528372 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
WFM too now with today's Aurora. Thanks! :)
This looks good in crash stats as well, last crash on Aurora was with 20110505042002.
Crash Signature: [@ nsPluginStreamListenerPeer::ServeStreamAsFile(nsIRequest*, nsISupports*)]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.