Closed Bug 816442 Opened 12 years ago Closed 12 years ago

crash in nsNPAPIPluginStreamListener::OnStartBinding @ QuickTime with Flip4Mac

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Version:
18 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(firefox17 unaffected, firefox18+ affected)

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox17 --- unaffected
firefox18 + affected

People

(Reporter: scoobidiver, Unassigned)

References

Details

(Keywords: crash, topcrash, Whiteboard: [startupcrash])

Crash Data

It's #1 top crasher in 18.0b1 on Mac. It first showed up in 18.0a1/20120912085832. The regression range might be: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=96287ad60bef&tochange=d260fcec71ce Signature GetPixBaseAddr More Reports Search UUID 7a4b6f12-7d2a-43d6-9aa6-e8ad62121128 Date Processed 2012-11-28 13:21:37 Uptime 8 Last Crash 18.6 minutes before submission Install Age 18.9 minutes since version was first installed. Install Time 2012-11-28 13:02:36 Product Firefox Version 18.0 Build ID 20121121075611 Release Channel beta OS Mac OS X OS Version 10.7.5 11G63 Build Architecture x86 Build Architecture Info family 6 model 15 stepping 6 Crash Reason EXC_BAD_ACCESS / KERN_INVALID_ADDRESS Crash Address 0xffffffffa0600f2f App Notes AdapterVendorID: 0x10de, AdapterDeviceID: 0x 393GL Context? GL Context+ GL Layers? GL Layers+ EMCheckCompatibility True Adapter Vendor ID 0x10de Adapter Device ID 0x 393 Frame Module Signature Source 0 QD GetPixBaseAddr 1 QuickTimeComponents QuickTimeComponents@0x601316 2 QuickTimeComponents QuickTimeComponents@0x606020 3 CarbonCore CarbonCore@0x424fd 4 CarbonCore CarbonCore@0xf143c 5 CarbonCore CarbonCore@0xf147c 6 QuickTimeComponents QuickTimeComponents@0x5fd7d5 7 CarbonCore CarbonCore@0x67414 8 CarbonCore CarbonCore@0x6745d 9 QuickTime QuickTime@0x4d3df 10 QuickTime QuickTime@0x4d2f4 11 QuickTime QuickTime@0x2f267 12 QuickTime QuickTime@0x2db2c 13 QuickTime QuickTime@0x336ae 14 Flip4Mac WMV Plugin Flip4Mac WMV Plugin@0x599e 15 Flip4Mac WMV Plugin Flip4Mac WMV Plugin@0x7459 16 XUL nsNPAPIPluginStreamListener::OnStartBinding dom/plugins/base/nsNPAPIPluginStreamListener.cpp:323 17 XUL CMMFRandTemplate 18 XUL nsHttp::ResolveAtom Mutex.h:83 19 XUL nsNPAPIPluginStreamListener::OnStartBinding dom/plugins/base/nsNPAPIPluginStreamListener.cpp:285 20 XUL CMMFRandTemplate 21 XUL nsRuleNode::GetStyleData layout/style/nsRuleNode.h:142 22 XUL nsPluginStreamListenerPeer::SetUpStreamListener dom/plugins/base/nsPluginStreamListenerPeer.cpp:1080 23 XUL nsPluginStreamListenerPeer::SetUpStreamListener dom/plugins/base/nsPluginStreamListenerPeer.cpp:1192 24 XUL _ZN7mozilla3cssL11kCharsetSymE 25 Flip4Mac WMV Plugin Flip4Mac WMV Plugin@0x72f2 26 libmozglue.dylib double_conversion::BignumDtoa mfbt/double-conversion/bignum-dtoa.cc:619 27 XUL CMMFRandTemplate 28 libsystem_c.dylib libsystem_c.dylib@0xb1922 29 XUL RDFServiceImpl::GetAnonymousResource::gChars ... More reports at: https://crash-stats.mozilla.com/report/list?signature=GetPixBaseAddr
Crash Signature: [@ GetPixBaseAddr] → [@ GetPixBaseAddr] [@ QD@0x188fe] [@ RegisterDrawingNotification] [@ QuickTime@0x3d24a] [@ QuickTime@0x2f443]
Summary: crash in nsNPAPIPluginStreamListener::OnStartBinding @ GetPixBaseAddr with Flip4Mac → crash in nsNPAPIPluginStreamListener::OnStartBinding @ QuickTime with Flip4Mac
I found one in the 20120906030518 build (bp-4b424e6e-eaf8-4a53-a84e-2f0d42121113). And in any case there seem to be too few of these to reliably establish a regression range. One odd thing: These appear all to be crashes in the main process, in 32-bit mode. But on OS X 10.6 and up we default to running all plugins out-of-process, and of course we default to running in 64-bit mode.
I can't find any of these dated earlier than 2012-11-26. So I'll bet we're dealing with a new version of Flip4Mac.
(In reply to Steven Michaud from comment #1) > One odd thing: These appear all to be crashes in the main process, in > 32-bit mode. But on OS X 10.6 and up we default to running all plugins > out-of-process, and of course we default to running in 64-bit mode. Some comments say: "caltran video. Crashed when going to the 32 bit mode" "Trying to open a page with a 32-bit plugin." "Tried to use this: <embed src="piano.mp3" type="application/x-mplayer2" autostart="true" playcount="true" loop="true" height="0" width="0"> FF asked to restart in 32bit mode, which I let it do, then it crashed on loading the page." (In reply to Steven Michaud from comment #2) > I can't find any of these dated earlier than 2012-11-26. There are plenty of crashes before, some on September 14th. > So I'll bet we're dealing with a new version of Flip4Mac. Firefox 17 is unaffected so it's a regression in the Firefox code.
> There are plenty of crashes before, some on September 14th. Please list some examples.
OK, thanks. I stand corrected.
> "Tried to use this: <embed src="piano.mp3" > type="application/x-mplayer2" autostart="true" playcount="true" > loop="true" height="0" width="0"> FF asked to restart in 32bit mode, > which I let it do, then it crashed on loading the page." This is interesting, and may provide a clue. Odd, though, that we prompt the user to restart in 32-bit mode. I thought we only did this for plugins that use the Carbon event model. I also though there no plugins left with significant market share that did this (see bug 598397). If it does turn out that Flip4Mac still uses the Carbon event model even in its most recent versions, we may need to consider explicitly dropping support for it.
Since this is a topcrasher, and therefore fairly urgent, I should probably deal with it. But I won't be the least bit sorry if someone else beats me to it. The first thing to do is to establish whether or not FF prompts to restart in 32-bit mode even with the most recent versions of Flip4Mac, and figure out why.
Assignee: nobody → smichaud
bug 766886 landed recently and touched this code on 18+
These crashes happen in builds that don't have that patch.
Flip4Mac actually has two current versions: 2.4.4 for OS X 10.5 and 10.6, and 3.0 for OS X 10.7 and 10.8. (http://www.telestream.net/flip4mac/overview.htm) Version 2.4.4 still uses the QuickTime plugin (as have previous versions of Flip4Mac). But version 3.0 doesn't. Testing on OS X 10.7.5 with current mozilla-central code, I find that both use CoreAnimation, and work just fine with the few examples I've found (for example http://www.wickham43.net/videoexamplewmp.php). Neither version requests/forces a restart in 32-bit mode.
QuickTime 7.7.1 (the current version on OS X 10.7.5) also uses CoreAnimation, and also works just fine (with current mozilla-central code). The following mp3 movie still loads in QuickTime, even when Flip3Mac has been installed and its default settings haven't been altered: http://fhuhs.org/fhuhs/dynamic/quicktime-examples/
The examples from comment #11 and comment #12 also work fine in FF 18.0b2, with either version of Flip4Mac (still testing on OS X 10.7.5).
This bug will probably be intractable until we can find a way to reproduce it. I suspect we can just add a relnote telling people who use Flip4Mac to make sure they've upgraded to the most recent version appropriate to their version of OS X.
Here is the breakdown by debug identifier on December 1st: 100% (19/19) vs. 15% (75/505) Flip4Mac WMV Plugin 16% (3/19) vs. 2% (9/505) 090F01C24E79421E4FA7EFBF0E5B50930 21% (4/19) vs. 1% (4/505) 0C0E8EEDE2516E9466C57CA8EAA711E30 21% (4/19) vs. 1% (7/505) 4D5979077C481F79317D4F2C859671E40 37% (7/19) vs. 7% (35/505) B41C15F21AD40A763659C1A4324AD7560 5% (1/19) vs. 1% (3/505) F0F119FC17AE8C721045E05990D23F450 (In reply to Steven Michaud from comment #14) > I suspect we can just add a relnote telling people who use Flip4Mac to make > sure they've upgraded to the most recent version appropriate to their > version of OS X. If you are sure it happens only with old Flip4Mac versions, you should blocklist it.
But right now we don't really know *which* versions to blocklist. I suppose we could get that information from the debug IDs you list, but it will be very painful: We'd need to run dump_syms on different versions of Flip4Mac, and I'm not sure older versions are still available to be downloaded.
For what it's worth, here are debug IDs for the current versions: Flip4Mac 2.4.4.2's Debug IDs for "Flip4Mac WMV Plugin" binary: i386 CD3E5781F809A4A3457735B123CBDD160 x86_64 8D1013A4324D4692232740B78A147BE40 Flip4Mac 3.0's Debug IDs for "Flip4Mac WMV Plugin" binary: i386 FCCBCFA0033F346C94E06B3F7EC433140 x86_64 8659463426CD3E3387E0A78D6E68195F0
> Flip4Mac 3.0's Debug IDs for "Flip4Mac WMV Plugin" binary: The full version number (from Info.plist) is 3.0.0.126.
> You can get earlier version of Flip4Mac by requesting them from support. > http://www.telestream.net/telestream-support/flip4mac-wmv/contact-support.htm http://forum.telestream.net/forum/messageview.aspx?catid=9&threadid=9383 So it'll be like pulling teeth :-(
(In reply to Steven Michaud from comment #19) > > You can get earlier version of Flip4Mac by requesting them from support. > > http://www.telestream.net/telestream-support/flip4mac-wmv/contact-support.htm > > http://forum.telestream.net/forum/messageview.aspx?catid=9&threadid=9383 > > So it'll be like pulling teeth :-( Can we make an in-product change that reports the full version number alongside the crash in appnotes?
(In reply to comment #20) That'd be difficult, because Breakpad doesn't actually get (or report) the full version number. Instead it uses dump_syms (or code therefrom) to generate a "debug ID" for each loaded module. It's possible (in principal) to deduce version numbers by comparing a crash-dump's debug IDs to ones generated from modules whose version is known. But this is laborious, and is sometimes impossible (when old versions aren't available for testing). You could argue that Breakpad should get the true version number from the Info.plist file of every module that's a plugin bundle's executable. But this would (I suspect) significantly complicate Breakpad's code.
> You could argue that Breakpad should get the true version number > from the Info.plist file of every module that's a plugin bundle's > executable. ... This needs rephrasing: You could argue that Breakpad should get the true version number (from the plugin bundle's Info.plist file) for every module that's a plugin bundle's executable. (If the module is a plugin bundle's executable, the bundle's Info.plist file will be in a known location relative to the module's location.) ...
I promised this same thing to Adobe at our most recent meeting, and it's now filed as bug 818664.
See https://crash-stats.mozilla.com/topcrasher/byos/Firefox/18.0b3/Mac%20OS%20X/7/browser - the GetPixBaseAddr signature remains #1 on 18.0b3 for the Mac-only list, any chance we get some progress here?
> any chance we get some progress here? I doubt it. These crashes aren't reproducible. However it does appear they don't happen with the latest versions of Flip4Mac. So we should probably follow Scoobidiver's suggestion to blocklist older versions. Which means that someone (not me) will need to figure out which versions to blocklist.
Assignee: smichaud → nobody
Depends on: 821422
There are no crashes in 18.0b7 because of bug 821422.
Status: NEW → RESOLVED
Closed: 12 years ago
status-firefox18: affected → fixed
Resolution: --- → FIXED
A few crashes have happened recently: https://crash-stats.mozilla.com/report/list?signature=GetPixBaseAddr
Status: RESOLVED → REOPENED
Keywords: topcrash
Resolution: FIXED → ---
I looked at the "debug ID" for "Flip4Mac WMV Plugin" in four of these reports, and none of them matched any of the debug IDs from comment #17. Maybe we should block any versions < 2.4.4.2, instead of < 2.4.4 (as per bug 821442 comment #0).
With combined signatures, it's #3 top browser crasher in 18.0 on Mac OS X. Here are recent correlations per Flip4Mac debug identifier: GetPixBaseAddr|EXC_BAD_ACCESS / KERN_INVALID_ADDRESS (15 crashes) 100% (15/15) vs. 3% (61/2285) Flip4Mac WMV Plugin 27% (4/15) vs. 0% (4/2285) 090F01C24E79421E4FA7EFBF0E5B50930 7% (1/15) vs. 0% (1/2285) 0C0E8EEDE2516E9466C57CA8EAA711E30 7% (1/15) vs. 0% (2/2285) 391C77A6CFE279CF9FD3FC83F52DC0010 7% (1/15) vs. 0% (5/2285) 4D5979077C481F79317D4F2C859671E40 13% (2/15) vs. 0% (7/2285) A0DDA63958EF49676194F7D204F966300 13% (2/15) vs. 0% (5/2285) AEE0C383ED2349E932E85B101544CB560 13% (2/15) vs. 1% (21/2285) B41C15F21AD40A763659C1A4324AD7560 7% (1/15) vs. 0% (5/2285) C7016A412437429BCB52261848B5BAE10 7% (1/15) vs. 0% (6/2285) F0F119FC17AE8C721045E05990D23F450 RegisterDrawingNotification|EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE (10 crashes) 100% (10/10) vs. 3% (61/2285) Flip4Mac WMV Plugin 10% (1/10) vs. 0% (2/2285) 4C8E04D0C3FD4451EA7261FEA1E490760 10% (1/10) vs. 0% (5/2285) 4D5979077C481F79317D4F2C859671E40 20% (2/10) vs. 0% (5/2285) AEE0C383ED2349E932E85B101544CB560 30% (3/10) vs. 1% (21/2285) B41C15F21AD40A763659C1A4324AD7560 20% (2/10) vs. 0% (5/2285) C7016A412437429BCB52261848B5BAE10 0% (0/10) vs. 0% (1/2285) CCC04D27D28E3EC02B710B756CD0B0F50 10% (1/10) vs. 0% (6/2285) F0F119FC17AE8C721045E05990D23F450 There are not enough blocklisted Flip4Mac versions.
status-firefox18: fixed → affected
Keywords: topcrash
(Following up comment #29) Once again, none of these debug IDs match those from comment #17. > There are not enough blocklisted Flip4Mac versions. I agree.
Oddly (maybe a forced Flip4Mac update or a code change), there are no crashes in 19.0 and above.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.