Closed Bug 649795 Opened 11 years ago Closed 11 years ago
crash [@ ns
Plugin Stream Listener Peer::Serve Stream As File(ns IRequest*, ns ISupports*)]
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.
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
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.
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 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.
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
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.
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.
OS: All → Windows 7
Hardware: All → x86
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?
Marcia, I mistakenly assumed I was running the most current version of Adobe, but instead I merely had the most recent 9.x (184.108.40.206, 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: 220.127.116.11 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.
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: 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.
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 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: http://hg.mozilla.org/mozilla-central/rev/84af3e2c7ac3
Status: NEW → RESOLVED
Closed: 11 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*)]
You need to log in before you can comment on or make changes to this bug.