363585 - WMP crashes when Firefox is in ns4xPluginStreamListener::OnDataAvailable

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Brian Polidoro]

This crash occurs in the WMP plugin.  But because this regressed without the plugin changing, it leads me to think it's our problem.  

10-24-2006 nightly ok
10-25-2006 nightly crashes

From that regression range and the location where Firefox is when the crash occurs it looks like a regression from bug 281153.  

From viewing the site in Fx 1.5.0.8 I see that the site when loading first shows the WMP plugin then the flash player loads and plays a video.  Perhaps it tries WMP but that can't play the video due to a missing codec or something like that.

Comment 1

[Ryan VanderMeulen [:RyanVM]]

Confirming that I've seen a lot of random weirdness with the WMP plugin on many sites. If it doesn't completely crash the browser, it can lead to hangups when the tab containing the embedded movie is closed.

Comment 2

[Ryan Jones-Ward [:sciguyryan]]

Confirmed, got a talkback ID too (TB27233540X) but it looks sort of bogus. 

Comment 3

[Boris Zbarsky [:bzbarsky]]

What are the hours on those nightly builds?  Or better yet, just a bonsai link to the regression range?  Bug 281153 didn't touch any plugin-related code at all, so I _really_ doubt this is a regression from that bug.

Comment 4

[Ryan VanderMeulen [:RyanVM]]

I'll do some date-specific checkouts and figure out what exactly's causing the crash

Comment 5

[Brian Polidoro]

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-10-24+04%3A00%3A00&maxdate=2006-10-25+04%3A00%3A00&cvsroot=%2Fcvsroot

Comment 6

[Boris Zbarsky [:bzbarsky]]

In that range my money is on bug 354984 or on some weird timing issue in the plugin...

Comment 7

[Boris Zbarsky [:bzbarsky]]

Ryan, if you _could_ narrow that down, that would rock!

Comment 8

[Ryan VanderMeulen [:RyanVM]]

BTW, I can reproduce the crash with the 10-24-06 nightly as well, so I think this regression dates further back than that.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

So far, I'm back to the June 01, 2006 build and I'm still seeing a crash. TB27238194Y is the latest (though I've noticed that the stack is different than some of the newer builds)

Comment 10

[Ryan VanderMeulen [:RyanVM]]

OK, from what I can tell, this regressed between the 05-10-06 and 05-11-06 nightly. Here's the bonsai range for that:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-10+3%3A30&maxdate=2006-05-11+7%3A30&cvsroot=%2Fcvsroot

If I had to wager a guess (which I'll work on confirming soon), something tells me that 326273 is the responsible checkin for this regression.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Yeppers, it's the thread manager that caused this.

Comment 12

[Mihail Daskalov]

if one needs recent talkback ID TB27285261X, TB27285119X, TB27285054W, TB27284727Y.

These shoiw however different traces.

2 of them are 
0x03302a28
0x03300448
0x01a07d00
nsPluginInstanceOwner::Init  [mozilla\layout\generic\nsobjectframe.cpp, line 3297]
0x4ca10000


and another two are
npdsplay.dll + 0x1ec13 (0x5f34ec13)
npdsplay.dll + 0x27ca9 (0x5f357ca9)
npdsplay.dll + 0x4c654 (0x5f37c654)
0x0456bf48
npdsplay.dll + 0x4c654 (0x5f37c654)
0x0456bf48
npdsplay.dll + 0x4c654 (0x5f37c654)
0x0456bf48
npdsplay.dll + 0x4c654 (0x5f37c654)
0x0456bf48
npdsplay.dll + 0x4c654 (0x5f37c654)
0x0456bf48
npdsplay.dll + 0x4c654 (0x5f37c654)
0x0456bf48
npdsplay.dll + 0x4c654 (0x5f37c654)
0x0456bf48
... etc, which looks similar to what is reported in talkback IDs cited in bug  340262

Comment 13

[Benjamin Smedberg]

Jay, can you sift through trunk talkback and let us know how prevalent this is (and whether there are particular WMP plugins involved)?

Comment 14

[Jay Patel [:jay]]

This looks a dupe of bug 340262, and it looks like the .dll + offset is the same for all of these crashes (at least for npdsplay.dll)... and there are a lot of them!

This currently the #3 topcrasher for FF30a1...
http://talkback-public.mozilla.org/reports/firefox/FF30a1/FF30a1-topcrashers.html

and all recent crashes can be queried with:
http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=npdsplay.dll&vendor=MozillaOrg&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=build&rlimit=0

That query is sorted by build, so all the Trunk crashes are at the top... and although there are a lot of crashes on the branches, the majority of them are from FF30a1 and other Trunk builds.

If you determine this to be a dupe of that other bug, feel free to copy over this info there.  This looks like a great candidate for improving stability on the Trunk.

Comment 15

[Johnny Stenback (:jst)]

This looks like it was fixed by bug 364028, applying that fix alone to a tree that doesn't have it makes this crash go away. Marking FIXED.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Huh.  Odd, since this regressed before the async javascript: changes.  Oh, well.  ;)