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

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Charles Fenwick]

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/message_loop.cc:219
13 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:202
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. http://www.nhc.noaa.gov/verification/pdfs/Verification_2010.pdf

First crash logged in nightly Apr 12, 2011 14:16. ~40 crashes logged since then.

Comment 1

[Robert Kaiser]

https://crash-stats.mozilla.com/report/list?signature=nsPluginStreamListenerPeer%3A%3AServeStreamAsFile%28nsIRequest%2A%2C%20nsISupports%2A%29 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]

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)]

Josh, bsmbedberg, this seems to be the nr 1 top crash, can you guys investigate here?

Comment 4

[Charles Fenwick]

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]

I am perfectly fine with backing out just http://hg.mozilla.org/mozilla-central/rev/3aebb305dee5, 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]

Also happens with Linux, see b5ba6da8-5750-45f5-b95e-0d7202110420. Aurora crashes every time I try to open http://portal.aauj.edu/portal_resources/downloads/programming/oreilly_advanced_perl_programming1997.pdf

Comment 7

[Benjamin Smedberg]

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]

Downloaded and tested a few nightlies on a fresh profile.

Apr 10 Built from http://hg.mozilla.org/mozilla-central/rev/fe3f7889918b no crash
Apr 11 Built from http://hg.mozilla.org/mozilla-central/rev/09b605eb3e0d no crash
Apr 12 Built from http://hg.mozilla.org/mozilla-central/rev/a174b86200d6 crash

For entertainment, tested today's nightly 
Built from http://hg.mozilla.org/mozilla-central/rev/46fdf12082d4

and unsurprisingly it crashed on the example link.

Comment 9

[Marcia Knous [:marcia]]

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]

Marcia, 

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

Upgraded to Adobe 10.0.1 and re-tested. Result: No crash.

Comment 11

[Marcia Knous [:marcia]]

Charles: Thanks for the update. I can reproduce the crash using Version: 9.4.0.195 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)]

Attachment: 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]

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:

http://hg.mozilla.org/mozilla-central/rev/3aebb305dee5#l22.36

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)]

The original use of mOwner came in here:

http://hg.mozilla.org/mozilla-central/rev/b1b57869cb43#l5.41

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]

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]]

This will help fix a top crash on the trunk and Aurora. Can someone check it in?

Comment 17

[Benjamin Smedberg]

jst went on vacation, so I guess I'll steal it.

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Landed on mozilla-central:
http://hg.mozilla.org/mozilla-central/rev/84af3e2c7ac3

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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]]

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]

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-4, no longer working on Mozilla)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/f328e9955f82

Comment 23

[Frédéric Buclin]

WFM too now with today's Aurora. Thanks! :)

Comment 24

[Marcia Knous [:marcia]]

This looks good in crash stats as well, last crash on Aurora was with 20110505042002.