spike in "corrupted plugin stream data" browser abort on mozilla-central [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | mozilla::plugins::PluginModuleParent::StreamCast(_NPP*, _NPStream*)]




8 years ago
7 years ago


(Reporter: dbaron, Unassigned)



Windows 7

Firefox Tracking Flags

(Not tracked)


(crash signature)

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:
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).

Comment 1

8 years ago
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.

Comment 2

8 years ago
Full changelog from the previous day to 2011-03-28:12


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?

Comment 3

8 years ago
Oddly enough, all the crashes take unusual-looking paths:




nsForceXMLListener::OnDataAvailable (this frame may be wrong, it could actually be a COMDAT-folded version of nsMultipartProxyListener::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.

Comment 4

8 years ago
(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:


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?

Comment 5

8 years ago
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?

Comment 6

8 years ago
I have Adblock Plus 1.3.6rc.2952 installed and can reproduce the crash with the Silverlight video on this URL:
Disabling Adblock Plus fixes it for me.

Comment 7

8 years ago
@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?

Comment 8

8 years ago
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.

Comment 9

8 years ago
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.

Comment 10

8 years ago
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

Comment 11

8 years ago
Ok, I found the source of the issue - catching exceptions in onStartRequest was clearly the wrong thing to do. I removed the try..catch blocks again. Does this mean that any JavaScript channel listener will necessarily spam error console with bogus error messages?

Comment 12

8 years ago
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.

Comment 14

8 years ago
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.

Comment 16

8 years ago
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.

Comment 18

8 years ago
(In reply to comment #17)
> > how can we get a raw JS exception back?
> You don't know you're calling XPCOM.  Don't assume that.

I think I do - even if the listener is implemented in JavaScript, it will be wrapped and any JavaScript exception will be turned into nsIXPCException. Anyway, I can change the catch blocks into |catch (e if e instanceof nsIException)| - raw JavaScript exceptions are unexpected and swallowing them is probably the wrong thing to do.
> it will be wrapped

My point was that this is an implementation detail you should not be depending on.

> Anyway, I can change the catch blocks into |catch (e if e instanceof
> nsIException)| - raw JavaScript exceptions are unexpected and swallowing them
> is probably the wrong thing to do.

That seems fine too, yes.

Comment 20

8 years ago
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*)]

Comment 21

8 years ago
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.
Keywords: topcrash

Comment 22

7 years ago
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.


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.

Comment 23

7 years ago
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!
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.

Comment 27

7 years ago
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


7 years ago
Depends on: 556643
Let's close this bug as the spike is gone.
Blocks: 556643
No longer depends on: 556643


7 years ago
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.