It looks like the crash described in bug 556643 has spiked in recent days on mozilla-central (though I don't see a similar spike on 4.0). It's possible it could be just a small number of users, but it looks like more than that. In particular, if you look at this *dated* query for nightly builds only: https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox:4.0b13pre&version=Firefox:4.2a1pre&query_search=signature&query_type=exact&query=&date=04%2F05%2F2011%2000%3A00%3A00&range_value=30&range_unit=days&hang_type=crash&process_type=browser&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=mozalloc_abort%28char%20const*%20const%29%20|%20NS_DebugBreak_P%20|%20mozilla%3A%3Aplugins%3A%3APluginModuleParent%3A%3AStreamCast%28_NPP*%2C%20_NPStream*%29 you'll see a rate that was averaging less than one crash per build up until the 28th, and then significantly more than that. It's hard to say exactly where the spike was, though, since there were two builds in a row with exactly one crash (2011-03-28 03 and 2011-03-28 10), and then every build since 2011-03-28 12 has had multiple crashes (except 2011-03-29 03, which had none).
Perhaps related is the new random orange bug 646275, where test_pluginstream_asfileonly is timing out. I looked through recent plugins changes and didn't see anything particularly suspicious: going to look through objectframe and netwerk changes next.
Full changelog from the previous day to 2011-03-28:12 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fbe53bc0d7f6&tochange=df9338ea288b I don't see anything really suspicious in there. Does this crash also spike in FF4 builds? Perhaps there was an Acrobat update around this time which is related?
Oddly enough, all the crashes take unusual-looking paths: https://crash-stats.mozilla.com/report/index/0d541508-9654-4b75-90af-b66892110318 nsHttpChannel::OnStopRequest nsMultiMixedConv::SendData nsPartChannel::SendOnDataAvailable nsPluginStreamListenerPeer::OnDataAvailable https://crash-stats.mozilla.com/report/index/c5e137c1-e714-4034-b749-6c27e2110331 nsStreamListenerTee::OnDataAvailable xpconnect nsForceXMLListener::OnDataAvailable (this frame may be wrong, it could actually be a COMDAT-folded version of nsMultipartProxyListener::OnDataAvailable) nsPluginStreamListenerPeer::OnDataAvailable https://crash-stats.mozilla.com/report/index/2b47b09f-45f1-47b9-8611-f6bf42110331 is the same basic pattern with nsMultipartProxyListener instead. Adblock plus 1.3.6rc.2952 appears to be installed in every report I've seen so far.
(In reply to comment #3) > Adblock plus 1.3.6rc.2952 appears to be installed in every report I've seen so > far. No, the first report you linked to actually has Adblock Plus 1.3.5b.2874 installed which is older than the currently released version. Then again, it is Firefox 4.0b13pre and not 4.2a1pre. These two reports have 4.2a1pre without any extensions however: https://crash-stats.mozilla.com/report/index/ac3f984c-13ee-43ea-b370-b8b112110331 https://crash-stats.mozilla.com/report/index/12fc0b0a-5232-4968-9621-c04572110331 Many of the reports have exactly the same extensions, not only Adblock Plus - looks like the same people are crashing in a loop. But if it is somehow related to recent Adblock Plus changes I would suspect attaching an own listener to HTTP channels via nsITraceableChannel (due to bug 645678, see https://hg.adblockplus.org/adblockplus/file/2952/modules/Utils.jsm#l617), everything else is too far away from plugins. That change landed on 29th, all the changes before it were only UI tweaks. Adblock Plus 1.3.6 is scheduled for release tomorrow, should I hold the release?
Hrm, I don't know how to interpret all that. I'm definitely worried about it. bz, could you look at trev's code and see if there's anything obviously wrong?
I have Adblock Plus 1.3.6rc.2952 installed and can reproduce the crash with the Silverlight video on this URL: http://channel9.msdn.com/blogs/scobleizer/raymond-chen-pdc-05-talk-five-things-every-win32-programmer-needs-to-know Disabling Adblock Plus fixes it for me.
@Omer Kehri: What about Adblock Plus 1.3.6a.2943 or Adblock Plus 1.3.6a.2938 (https://adblockplus.org/devbuilds/adblockplus/), do you get a crash with these as well?
Never mind, I can reproduce the crash on http://viewer.zmags.com/publication/44230ae3#/44230ae3/1 with Flash. With Adblock Plus 1.3.6a.2946 it works fine, with Adblock Plus 1.3.6rc.2951 it crashes. The new channel listener is essentially the only change between these two builds.
I tested the last 5 ABP builds: 2938 works 2943 works 2946 works 2951 crashes 2952 crashes BTW, "works" means "does not crash", the video does not load, even with IE9. I can test additional builds from you as I can reproduce it regularly.
FWIW Minefield just crashed like bp-e3c48233-7709-4697-a743-21f292110331 when using Google's StreetView on Mozilla/5.0 (Windows NT 6.0; rv:2.2a1pre) Gecko/20110331 Firefox/4.2a1pre ID:20110331030432 with Adblock Plus 1.3.6rc.2952
Adblock Plus 1.3.6rc.2955 should no longer cause this crash. It will cause frequent error messages to be posted to the error console however (NS_ERROR_FAILURE when calling onStartRequest). Not sure I can release it like this...
You can catch the exceptions as long as you make sure to call cancel() on the channel accordingly, right? Note that I haven't read/digested the early comments or the code yet; this is based purely on reading comment 11.
Thanks, Boris, I've done that: https://hg.adblockplus.org/adblockplus/rev/e5d1332a92b9. I'll wait until Monday, if no issues pop up until then I'll release it.
OK, now I've read through the whole thing. The change linked to in comment 14 is almost correct. Safer would be to check whether e.result is a failure code and if not to default to some innocuous error code like NS_BINDING_ABORTED for the cancel call. Otherwise things might go wrong if |e| is a raw JS exception, not an xpconnect-generated one, since calling cancel(NS_OK), which is what would happen in that situation, is not really good practice. Other than that, it does look like the old code in abp would trigger the sort of issues we're seeing.
Boris, we are calling XPCOM here - how can we get a raw JS exception back? And how can e.result be a success code, it wouldn't even be converted to an exception.
> how can we get a raw JS exception back? You don't know you're calling XPCOM. Don't assume that. > And how can e.result be a success code, It can be undefined if this is not an XPCOM-generated exception, which will convert to 0 as a number when you pass it to cancel(), which is NS_OK.
Looking at the crash stats, this particular crash signature disappeared again for 4.2a1pre after April 1st - only two crashes on April 3rd from the same user using an old Adblock Plus development build, otherwise nothing. Seems to be safe to release Adblock Plus 1.3.6 now.
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | mozilla::plugins::PluginModuleParent::StreamCast(_NPP*, _NPStream*)]
This is still around and reasonably high volume. About 2000 of these on 8.0 in the past 4 weeks which puts in in the #84 spot. I don't think it's still a top crash though so removing the keyword.
I've just encountered this bug twice this morning, after never seeing the bug before. I was using the May 29th nighty with cset 79262a88881d, when it occurred. I haven't watched any video after the respin (cset 78852a6d11ab), so I'm not sure if it's still present. http://crash-stats.mozilla.com/report/index/bp-cab3574f-2994-4945-a8a2-7c4cc2120529 http://crash-stats.mozilla.com/report/index/bp-98905052-02b7-474a-a259-b2d7b2120529 Both seemed to have happened after reloading a page with a video that had finished playing. A few seconds into the video replaying (after the page reloaded) the browser crashed. Beyond that, I have no STR.
By the way, they were both flash video: one on msnbc and the other on youtube.
Bug 758224 landed on 24-May, although I'd be surprised if that caused this. Bug 719117 and the backout of bug 724781 landed on 26-May and were landed onto aurora and beta; if they are causing this crash to spike we need to figure that out ASAP!
IU, currently your two reports are the only two reports for a recent buildid, so this may just be an unlucky coincidence, but we should keep our eye on the report volume today and tomorrow. https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A15.0a1&query_search=signature&query_type=contains&query=PluginModuleParent%3A%3AStreamCast&reason_type=contains&date=05%2F29%2F2012%2018%3A10%3A34&range_value=1&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=mozalloc_abort%28char%20const*%20const%29%20|%20NS_DebugBreak_P%20|%20mozilla%3A%3Aplugins%3A%3APluginModuleParent%3A%3AStreamCast%28_NPP*%2C%20_NPStream*%29
It's #55 top browser crasher in 12.0, #88 in 13.0b5, #65 in 16.0b6, #25 in 13.0b7, #49 in 14.0a2, and #172 in 15.0a1.
I've had this Crash in both firefox 13 and 14. running windows 7 64bit. Crash reporter claims issue casued by flash 64bit plugin, flash versions 11.3 and 11.4 have been tested and exibit same behaviour. Issue is easily reproducable by going to google maps going in to streetview mode and moving and panning around for 2 minutes My last crash report has ID # 5adefc86-6614-4d68-8c28-18fed2120822 Hope this helps agent42
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.