426524 - Crash on window/tab close with Flip4Mac plugin [@ ns4xPluginInstance::Stop()][@ CopyBits]

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P2)

Description

[Michael Schonfeld]

Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040204 Minefield/3.0pre.

Firefox crashes when trying to load www.danone.co.il.

Comment 1

[Steven Michaud [:smichaud] (Retired)]

There's a Flip4Mac plugin on that page (http://www.danone.co.il/), so
this is likely a Flip4Mac problem.  (I'm unable to reproduce this
problem, but I also don't have Flip4Mac.)

Comment 2

[Michael Schonfeld]

True, this is caused by the Flip4Mac plug-in, and disabling it will "fix" this crash. However, Safari does manage to successfully load this website with the Flip4Mac plug-in.  So I'm guessing this is some kind of an issue with Flip4Mac and Firefox...

Comment 3

[Steven Michaud [:smichaud] (Retired)]

Does the crash also happen in Firefox 2.0.0.13?

Have you updated to the latest version of Flip4Mac?

Comment 4

[Michael Schonfeld]

Yes. Crash also occurs on Firefox 2.0.0.13.

Yes. Flip4Mac is updated to its latest available version.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

Attachment: Gdb trace with debug symbols

I don't crash loading the page (http://www.danone.co.il/).  But I do
crash when (after having loaded the page) I quit the browser, or close
the window (or tab) containing the plugin.  My crashlog indicates this
happens (in Flip4Mac code) when the browser tells the Flip4Mac plugin
to "stop".

The fact that the crash happens in Flip4Mac code suggests it's caused
by a bug in the Flip4Mac plugin.  But the fact that the crash doesn't
happen in Safari suggests Firefox is doing something to trigger the
bug in Flip4Mac.

I tested with a build (one containing debug symbols) made from code
pulled on Monday (so it's more-or-less equivalent to the Minefield
2008-03-31 nightly).  I tested on OS X 10.5.2.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

The same crash also happens in Camino (on the trunk).

But I _don't_ crash in Firefox 2.0.0.13 or Camino 1.5.5.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

I don't crash on load with today's Minefield and Camino trunk nightlies.

I do crash (the same crash) on closing a window/tab containing a Flip4Mac plugin.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

I'm nominating this for blocking to get it on the radar.

This bug may be a dup ... I haven't really checked.  But even if it
is, it probably has better info than any of the other bugs.  If so,
they should be duped to this one, rather than the other way around.

Sam Sidler, Gavin Sharp:  Are either of you aware of any other reports
of Flip4Mac problems?

Comment 9

[Steven Michaud [:smichaud] (Retired)]

I see a small number of reports of this crash over the last couple of months (all in Flip4Mac code):

http://crash-stats.mozilla.com/report/list?range_unit=months&query_search=signature&query_type=exact&platform=mac&branch=1.9&signature=CopyBits&query=CopyBits&range_value=2

Comment 10

[timeless]

please send feedback to http://dynamic.flip4mac.com/request.asp

Comment 11

[Damon Sicore (:damons)]

+'ing this to get closure.  Popular plugin.  Let's find out if this is a Flip4Mac problem ASAP.

Comment 12

[Samuel Sidler (old account; do not CC)]

Josh has contacts at Telestream that can probably help here.

Comment 13

[Greg Wishart]

I'm the Telestream guy (or one of them anyway).  I just went to www.danone.co.il using FireFox 2.0.0.13 and Flip4Mac WMV 2.2.0.50 which is one release after our major release in January of 2.2.0.49.  Didn't get a crash.  Using Leopard on an Intel mac.  Using QT 7.4.1 (14).

I'll forward the URL to our QA people and see what they get...

Comment 14

[Greg Wishart]

FYI: 2.2.0.50 does not contain a fix we're putting in for Camino (that'll be released around May '08)

Comment 15

[Steven Michaud [:smichaud] (Retired)]

> using FireFox 2.0.0.13

Of course, you also need to test with Minefield and Camino trunk nightlies.

Comment 16

[Chris Lawson (gone)]

(In reply to comment #5)
> I don't crash loading the page (http://www.danone.co.il/).  But I do
> crash when (after having loaded the page) I quit the browser, or close
> the window (or tab) containing the plugin.  My crashlog indicates this
> happens (in Flip4Mac code) when the browser tells the Flip4Mac plugin
> to "stop".

That sounds pretty much exactly like the circumstances required to get some of our peskier Flash crashes to happen. See, in particular, bug 374630.

Might there be some way they're related?

Comment 17

[Steven Michaud [:smichaud] (Retired)]

> Might there be some way they're related?

I doubt it.

The crashes reported at bug 374630 are occasional, and only some of
them happen on ns4xPluginInstance::Stop().  They're also
1.8-branch-only.  The crash I report in comment #5 is 100%
reproducible, trunk-only, and always happens in
ns4xPluginInstance::Stop() (in plugin code).

But thanks for mentioning it -- it may turn out that you're right.

Comment 18

[Honza Bambas (:mayhemer)]

Attachment: Crash 2

I have a different crash, 100% reproducible. Sometimes it crashes in RGBForeColor, sometimes as I report. So, it is probably some uninitialized memory access/usage.

Comment 19

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #18)

Please give us the steps to reproduce.

Comment 20

[Honza Bambas (:mayhemer)]

(In reply to comment #19)
> (In reply to comment #18)
> 
> Please give us the steps to reproduce.
> 

STR for crash 2:
- use trunk build not older then 4 days
- open the URL http://www.danone.co.il/
- close the window (red button) => crash

I am not sure this is the same bug, but this happens when I try the STR for this bug in 100% cases.

I found a lot of reports with the same signature: http://crash-stats.mozilla.com/report/list?range_unit=weeks&query_search=signature&query_type=contains&signature=RGBForeColor&query=RGBForeColor&range_value=1

One of them has very close STR: http://crash-stats.mozilla.com/report/index/c0ea6bae-05ec-11dd-99ea-0013211cbf8a

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This is also reproducible for me in 100% of tries and Flip4Mac v2.2. The debugger gives following stack trace:

#0  0x9171ffa3 in RGBForeColor ()
#1  0x9436c2c8 in TaskMovie_priv ()
#2  0x944881b8 in frequentlyTaskMovies ()
#3  0x92e28a4a in TimerVector ()
#4  0x9082d74a in CFRunLoopRunSpecific ()
#5  0x9082ca36 in CFRunLoopRunInMode ()
#6  0x92df0878 in RunCurrentEventLoopInMode ()
#7  0x92defeb9 in ReceiveNextEventCommon ()
#8  0x92defdd9 in BlockUntilNextEventMatchingListInMode ()
#9  0x932960e5 in _DPSNextEvent ()
#10 0x93295cd7 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#11 0x1565ff13 in nsAppShell::ProcessNextNativeEvent (this=0x2933f70, aMayWait=0) at /Users/Shared/Projects/mozilla/source/mozilla/widget/src/cocoa/nsAppShell.mm:521
#12 0x156968d7 in nsBaseAppShell::DoProcessNextNativeEvent (this=0x2933f70, mayWait=0) at /Users/henrik/Projects/mozilla/source/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:151
#13 0x15696e16 in nsBaseAppShell::OnProcessNextEvent (this=0x2933f70, thr=0x2916080, mayWait=0, recursionDepth=0) at /Users/henrik/Projects/mozilla/source/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:278
#14 0x15660479 in nsAppShell::OnProcessNextEvent (this=0x2933f70, aThread=0x2916080, aMayWait=0, aRecursionDepth=0) at /Users/Shared/Projects/mozilla/source/mozilla/widget/src/cocoa/nsAppShell.mm:656
#15 0x013977ab in nsThread::ProcessNextEvent (this=0x2916080, mayWait=0, result=0xbfffe3e4) at /Users/henrik/Projects/mozilla/source/mozilla/xpcom/threads/nsThread.cpp:497
#16 0x0133b331 in NS_ProcessPendingEvents_P (thread=0x2916080, timeout=20) at nsThreadUtils.cpp:180
#17 0x15696843 in nsBaseAppShell::NativeEventCallback (this=0x2933f70) at /Users/henrik/Projects/mozilla/source/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:121
#18 0x156615f9 in nsAppShell::ProcessGeckoEvents (aInfo=0x2933f70) at /Users/Shared/Projects/mozilla/source/mozilla/widget/src/cocoa/nsAppShell.mm:299
#19 0x9082cfc2 in CFRunLoopRunSpecific ()
#20 0x9082ca36 in CFRunLoopRunInMode ()
#21 0x92df0878 in RunCurrentEventLoopInMode ()
#22 0x92defeb9 in ReceiveNextEventCommon ()
#23 0x92defdd9 in BlockUntilNextEventMatchingListInMode ()
#24 0x932960e5 in _DPSNextEvent ()
#25 0x93295cd7 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#26 0x9328fa64 in -[NSApplication run] ()
#27 0x156600bf in nsAppShell::Run (this=0x2933f70) at /Users/Shared/Projects/mozilla/source/mozilla/widget/src/cocoa/nsAppShell.mm:588
#28 0x172df34f in nsAppStartup::Run (this=0x2958890) at /Users/henrik/Projects/mozilla/source/mozilla/toolkit/components/startup/src/nsAppStartup.cpp:181
#29 0x00210b66 in XRE_main (argc=3, argv=0xbffff8c4, aAppData=0x290b5d0) at /Users/Shared/Projects/mozilla/source/mozilla/toolkit/xre/nsAppRunner.cpp:3170
#30 0x00002798 in main (argc=3, argv=0xbffff8c4) at /Users/Shared/Projects/mozilla/source/mozilla/browser/app/nsBrowserApp.cpp:158

Frame 11 is the last one in our source:
(gdb) frame 11
#11 0x1565ff13 in nsAppShell::ProcessNextNativeEvent (this=0x2933f70, aMayWait=0) at /Users/Shared/Projects/mozilla/source/mozilla/widget/src/cocoa/nsAppShell.mm:521
521	in /Users/Shared/Projects/mozilla/source/mozilla/widget/src/cocoa/nsAppShell.mm

The crash happens in this line:

    moreEvents = ([NSApp nextEventMatchingMask:NSAnyEventMask
                                     untilDate:nil
                                        inMode:currentMode
                                       dequeue:NO] != nil);

Timeless, could the crashes correlate with each other or are they different?

Comment 22

[Brian Crowder]

Bug 425157, comment 14 sounds like volunteering to me.  ;)

Comment 23

[Mats Palmgren (inactive)]

Attachment: wallpaper

A wallpaper that seems to fix the crashes at the URL.
This is as far as I'm willing to volunteer for this bug ;-)

Here's a MozillaTry build with this patch for testing:
https://build.mozilla.org/tryserver-builds/2008-04-14_15:[e-mail]-426524_wip1/

Are there other sites besides http://www.danone.co.il that uses
this plugin? (crashing or not)

Comment 24

[Chris Lawson (gone)]

(In reply to comment #23)
> Are there other sites besides http://www.danone.co.il that uses
> this plugin? (crashing or not)

Flip4Mac is the only supported way to view WMV content on the Mac. Microsoft discontinued their WMV plugin a while back and said "Use F4M instead".

cl

Comment 25

[Brian Crowder]

Mats:  Won't this wallpaper conflict with the wallpaper from your other bug?  Would you mind terribly doing a dependent patch, or updating this one after you've landed the other?  If I'm wrong about that, sorry.

Comment 26

[Mats Palmgren (inactive)]

I'll post a new patch.  I realized that testing the instance MIME type
isn't a very good strategy since a plugin could have a long list
and there's no guarantee the type actually is for the plugin we want.
What we want to match is the *plugin name*, but I found that getting
that name from DoStopPlugin() isn't so easy.

For example, the Flip4Mac crash in bug 376971 is an instance
for "audio/x-ms-wma". (and, uhm, I realize now that the wallpaper
for bug 425157 is most likely incomplete too)

Comment 27

[Mats Palmgren (inactive)]

Attachment: wallpaper, rev. 2

Don't do delayed stop for Flip4Mac, now matching on the plugin name.
(this also fixes the crash in bug 376971)

Match on plugin name for QuickTime too, to make the fix for bug 425157
more general and precise.

MozillaTry builds for testing:
https://build.mozilla.org/tryserver-builds/2008-04-14_21:[e-mail]-426524_2/

Comment 28

[Honza Bambas (:mayhemer)]

Other site using this plugin could be: http://www.play.cz/listen/listen.php?sh=radio1&bitrate=128

Comment 29

[Johnny Stenback (:jst)]

Comment on attachment 315701 [details] [diff] [review]
wallpaper, rev. 2

Mats, this looks good, but it seems like this would be doable with less code if you just exposed GetPluginName() on nsIPluginHost (as you did) and called that directly from the code in nsObjectFrame.cpp. A plugin instance owner already has a reference to the plugin host (mPluginHost), so you could just get that and make the call and that way avoid the new nsPluginInstancePeerVariable etc. You wanna try that, or is there a reason to go with this approach instead?

Comment 30

[Mats Palmgren (inactive)]

Attachment: wallpaper, rev. 3

Comment 31

[Johnny Stenback (:jst)]

Comment on attachment 315838 [details] [diff] [review]
wallpaper, rev. 3

Look good, r+sr=jst

Comment 32

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 315838 [details] [diff] [review]
wallpaper, rev. 3

a1.9=beltzner

Comment 33

[Mats Palmgren (inactive)]

mozilla/layout/generic/nsObjectFrame.cpp 	1.651
mozilla/modules/plugin/base/public/nsPIPluginHost.idl 	1.4
mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp 	1.607 

-> FIXED

Comment 34

[Carsten Book [:Tomcat]]

verified fixed using the steps to reproduce from this bug - Flip4Mac Windows Media Plugin 2.2 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008050621 Firefox/3.0pre - no crash 

--> Verified fixed

Comment 35

[[e-mail]]

How do I install the fix on my computer?

Comment 36

[Mats Palmgren (inactive)]

Install the Firefox 3.0pre build from here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 37

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #36)
> Install the Firefox 3.0pre build from here:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Stephen, these are developer builds and no official release. Please only use them for testing purposes. 

Comment 38

[Boris Zbarsky [:bzbarsky]]

Shouldn't that method be [notxpcom] in the idl?  Or at least document its non-XPCOM ownership model?  Or _something_?  As written, it's trivial to crash with this API.

Comment 39

[Mats Palmgren (inactive)]

Attachment: Use [shared] and add comment

I found [shared] at:
http://www.mozilla.org/scriptable/xpidl/idl-authors-guide/keywords.html

And sorry for the lack of proper documentation.

Comment 40

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 321542 [details] [diff] [review]
Use [shared] and add comment

Ah, indeed.  [shared] is perfect here.  This looks great!

Comment 41

[Mats Palmgren (inactive)]

Comment on attachment 321542 [details] [diff] [review]
Use [shared] and add comment

Landed in mozilla-central in bug 434429.