Closed Bug 426524 Opened 14 years ago Closed 14 years ago

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

Categories

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

All
macOS
defect

Tracking

()

VERIFIED FIXED
mozilla1.9

People

(Reporter: dev, Assigned: mats)

References

()

Details

Attachments

(4 files, 2 obsolete files)

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.
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.)
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
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...
Does the crash also happen in Firefox 2.0.0.13?

Have you updated to the latest version of Flip4Mac?
Yes. Crash also occurs on Firefox 2.0.0.13.

Yes. Flip4Mac is updated to its latest available version.
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.
Summary: Firefox crashes when loading this site → Crash on window/tab close with Flip4Mac plugin
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.
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.
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?
Flags: blocking1.9?
Summary: Crash on window/tab close with Flip4Mac plugin → Crash on window/tab close with Flip4Mac plugin [@ ns4xPluginInstance::Stop()][@ CopyBits]
please send feedback to http://dynamic.flip4mac.com/request.asp
+'ing this to get closure.  Popular plugin.  Let's find out if this is a Flip4Mac problem ASAP.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Josh has contacts at Telestream that can probably help here.
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...
FYI: 2.2.0.50 does not contain a fix we're putting in for Camino (that'll be released around May '08)
> using FireFox 2.0.0.13

Of course, you also need to test with Minefield and Camino trunk nightlies.
(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?
> 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.
Attached file 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.
(In reply to comment #18)

Please give us the steps to reproduce.
Attachment #315577 - Attachment is patch: false
(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
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?
Hardware: Macintosh → All
Bug 425157, comment 14 sounds like volunteering to me.  ;)
Assignee: nobody → mats.palmgren
Attached patch wallpaper (obsolete) — Splinter Review
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:16-mpalmgren@mozilla.com-426524_wip1/

Are there other sites besides http://www.danone.co.il that uses
this plugin? (crashing or not)
(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
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.
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)
Blocks: 376971, 425157
Status: NEW → ASSIGNED
Attachment #315657 - Attachment is obsolete: true
Attached patch wallpaper, rev. 2 (obsolete) — Splinter Review
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:40-mpalmgren@mozilla.com-426524_2/
Attachment #315701 - Flags: superreview?(jst)
Attachment #315701 - Flags: review?(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?
Attachment #315701 - Attachment is obsolete: true
Attachment #315838 - Flags: superreview?(jst)
Attachment #315838 - Flags: review?(jst)
Attachment #315701 - Flags: superreview?(jst)
Attachment #315701 - Flags: review?(jst)
Comment on attachment 315838 [details] [diff] [review]
wallpaper, rev. 3

Look good, r+sr=jst
Attachment #315838 - Flags: superreview?(jst)
Attachment #315838 - Flags: superreview+
Attachment #315838 - Flags: review?(jst)
Attachment #315838 - Flags: review+
Attachment #315838 - Flags: approval1.9?
Comment on attachment 315838 [details] [diff] [review]
wallpaper, rev. 3

a1.9=beltzner
Attachment #315838 - Flags: approval1.9? → approval1.9+
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
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9
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


Status: RESOLVED → VERIFIED
How do I install the fix on my computer?
Install the Firefox 3.0pre build from here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
(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. 
Blocks: 416953
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.
I found [shared] at:
http://www.mozilla.org/scriptable/xpidl/idl-authors-guide/keywords.html

And sorry for the lack of proper documentation.
Attachment #321542 - Flags: superreview?(bzbarsky)
Attachment #321542 - Flags: review?(bzbarsky)
Comment on attachment 321542 [details] [diff] [review]
Use [shared] and add comment

Ah, indeed.  [shared] is perfect here.  This looks great!
Attachment #321542 - Flags: superreview?(bzbarsky)
Attachment #321542 - Flags: superreview+
Attachment #321542 - Flags: review?(bzbarsky)
Attachment #321542 - Flags: review+
Depends on: 434429
Comment on attachment 321542 [details] [diff] [review]
Use [shared] and add comment

Landed in mozilla-central in bug 434429.
You need to log in before you can comment on or make changes to this bug.