Closed Bug 426524 Opened 14 years ago Closed 14 years ago
Crash on window/tab close with Flip4Mac plugin [@ ns4x
Plugin Instance::Stop()][@ Copy Bits]
2.59 KB, text/plain
2.90 KB, text/plain
7.75 KB, patch
|Details | Diff | Splinter Review|
4.48 KB, patch
|Details | Diff | Splinter Review|
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 18.104.22.168? Have you updated to the latest version of Flip4Mac?
Yes. Crash also occurs on Firefox 22.214.171.124. 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 126.96.36.199 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?
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
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 188.8.131.52 and Flip4Mac WMV 184.108.40.206 which is one release after our major release in January of 220.127.116.11. 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: 18.104.22.168 does not contain a fix we're putting in for Camino (that'll be released around May '08)
> using FireFox 22.214.171.124 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.
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.
(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
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:email@example.com_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)
Attachment #315657 - Attachment is obsolete: true
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:firstname.lastname@example.org_2/
Other site using this plugin could be: http://www.play.cz/listen/listen.php?sh=radio1&bitrate=128
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 on attachment 315838 [details] [diff] [review] wallpaper, rev. 3 Look good, r+sr=jst
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.
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.
Comment on attachment 321542 [details] [diff] [review] Use [shared] and add comment Ah, indeed. [shared] is perfect here. This looks great!
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.