Closed Bug 816442 Opened 12 years ago Closed 11 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: 11 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: 11 years ago → 11 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.