Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 649795 - crash [@ nsPluginStreamListenerPeer::ServeStreamAsFile(nsIRequest*, nsISupports*)]
: crash [@ nsPluginStreamListenerPeer::ServeStreamAsFile(nsIRequest*, nsISuppor...
: crash, regression
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: 5 Branch
: All All
: -- critical (vote)
: mozilla5
Assigned To: Johnny Stenback (:jst,
: Benjamin Smedberg [:bsmedberg]
Depends on:
  Show dependency treegraph
Reported: 2011-04-13 13:56 PDT by Charles Fenwick
Modified: 2013-12-27 14:30 PST (History)
15 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Likely fix. (742 bytes, patch)
2011-04-26 11:42 PDT, Johnny Stenback (:jst,
benjamin: review+
bugzilla: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Charles Fenwick 2011-04-13 13:56:02 PDT
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.
Comment 1 Robert Kaiser 2011-04-14 11:29:01 PDT 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.
Comment 2 Sheila Mooney 2011-04-19 10:04:15 PDT
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.
Comment 3 Johnny Stenback (:jst, 2011-04-19 15:34:19 PDT
Josh, bsmbedberg, this seems to be the nr 1 top crash, can you guys investigate here?
Comment 4 Charles Fenwick 2011-04-20 14:18:00 PDT
Timing of the patch for bug 617539 landing (changeset 67851:3aebb305dee5) and the appearance of this crash seems to suggest the two are related.
Comment 5 Benjamin Smedberg [:bsmedberg] 2011-04-20 14:22:57 PDT
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.
Comment 6 Frédéric Buclin 2011-04-20 15:24:44 PDT
Also happens with Linux, see b5ba6da8-5750-45f5-b95e-0d7202110420. Aurora crashes every time I try to open
Comment 7 Benjamin Smedberg [:bsmedberg] 2011-04-21 11:27:14 PDT
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.
Comment 8 Charles Fenwick 2011-04-21 14:16:29 PDT
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.
Comment 9 Marcia Knous [:marcia - use ni] 2011-04-25 15:35:15 PDT
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?
Comment 10 Charles Fenwick 2011-04-25 17:03:17 PDT

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.
Comment 11 Marcia Knous [:marcia - use ni] 2011-04-26 10:56:59 PDT
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.
Comment 12 Johnny Stenback (:jst, 2011-04-26 11:42:10 PDT
Created attachment 528372 [details] [diff] [review]
Likely fix.

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().
Comment 13 Benjamin Smedberg [:bsmedberg] 2011-04-26 11:49:38 PDT
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.
Comment 14 Johnny Stenback (:jst, 2011-04-26 12:49:08 PDT
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 15 Benjamin Smedberg [:bsmedberg] 2011-04-27 07:07:35 PDT
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!
Comment 16 Marcia Knous [:marcia - use ni] 2011-04-29 13:54:36 PDT
This will help fix a top crash on the trunk and Aurora. Can someone check it in?
Comment 17 Benjamin Smedberg [:bsmedberg] 2011-04-29 14:09:57 PDT
jst went on vacation, so I guess I'll steal it.
Comment 18 David Baron :dbaron: ⌚️UTC-7 2011-05-03 13:22:49 PDT
Landed on mozilla-central:
Comment 19 David Baron :dbaron: ⌚️UTC-7 2011-05-04 17:33:43 PDT
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.)
Comment 20 Marcia Knous [:marcia - use ni] 2011-05-05 10:50:14 PDT
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.
Comment 21 Charles Fenwick 2011-05-05 14:12:51 PDT
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.
Comment 22 David Baron :dbaron: ⌚️UTC-7 2011-05-05 15:30:02 PDT
Comment 23 Frédéric Buclin 2011-05-06 12:25:31 PDT
WFM too now with today's Aurora. Thanks! :)
Comment 24 Marcia Knous [:marcia - use ni] 2011-05-10 13:49:30 PDT
This looks good in crash stats as well, last crash on Aurora was with 20110505042002.

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