Closed Bug 1146036 Opened 9 years ago Closed 9 years ago

Adobe Flash 17.0.0.134/169 crashing on Flash thread in libGL.dylib in FF 34 and up

Categories

(External Software Affecting Firefox Graveyard :: Flash (Adobe), defect)

Product:
External Software Affecting Firefox Graveyard
Component:
Flash (Adobe)
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(firefox37 affected)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox37 --- affected

People

(Reporter: greenythebeast, Unassigned)

References

(
URL
)

Details

(6 keywords, Whiteboard: [STR for Flash 17.0.0.169 in comment #47])

Crash Data

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150320202338

Steps to reproduce:

Firefox 36.0.4
Mac OS X 10.10.2
Flash 17.0.0.134

Open youtube video: https://www.youtube.com/watch?v=ISkPmnSJDGM


Actual results:

Flash crashes and offers to submit a crash report

https://crash-stats.mozilla.com/report/index/40e8cf27-0a2d-402f-a995-2fba42150321


Expected results:

Video should have played. Does not occur on all youtube videos but the one I mentioned seems to create the problem constantly.
Crash Signature: https://crash-stats.mozilla.com/report/index/40e8cf27-0a2d-402f-a995-2fba42150321
Keywords: flashplayer
Severity: normal → critical
Crash Signature: https://crash-stats.mozilla.com/report/index/40e8cf27-0a2d-402f-a995-2fba42150321 → [@ glBindBufferARB ]
Component: Untriaged → Flash (Adobe)
Keywords: crash, crashreportid
Product: Firefox → Plugins
Version: 36 Branch → unspecified
Jeromie, I can reproduce this Flash crash very easily.

I have tested Firefox 36.0.4 and Beta 37 with Flash Player 17.0.0.134 on Mac OS X 10.10.2.
Thanks.  I'm not seeing it on my OSX 10.10.2 machine.  Can you give me hardware details on the machine that reproduces this?  I'd like to find a comparable machine to test with.
I think this is a HiDPI/Retina bug. I have two MacBook Pros, but I can reproduce the crash (with the YouTube URL in comment 0 and the dash-player.com URL in comment 1) on both but only when I load the Flash video on my MBP's built-in HiDPI Retina and not my external monitor.

MBP #1
MacBook Pro (Retina, Mid 2012)
2.6 GHz Intel Core i7
16 GB 1600 MHz DDR3
Intel HD Graphics 4000 1024 MB

MBP #2
MacBook Pro (Retina, 13-inch, Late 2013)
2.8 GHz Intel Core i7
16 GB 1600 MHz DDR3
Intel Iris 1536 MB
Interestingly, I can reproduce this in FF 36.0.4 but not FF 36.0.1.  So I suspect we're doing something wrong here.

I tested with the URL from comment #1 on OS X 10.10.2 on my Retina MacBook Pro with no external monitor attached.  I waited until the movie had played for a few minutes, then moved the slider forward once ... and crashed.
bp-17ec8f2f-fb9e-4be8-9877-5ff192150402

My crash report has a different "signature", but otherwise is a lot like the one from comment #0.
Let me see if I can find a regression range.
Oops, sigh.  I just reproduced this in FF 36.0.1.  Let me play around a bit before drawing any more conclusions.
No problem.  The retina tip helps.  I'm running Yosemite on a pre-retina machine.
Also, this is ADBE 3964200
Among FF releases, I can (I think) reproduce these crashes in FF 34 but not FF 33.

Chris, could you try to confirm or disconfirm this?
Flags: needinfo?(cpeterson)
Yes. This looks like a regression in 34. I can reproduce the crash with 34 but not 33.
Flags: needinfo?(cpeterson)
Keywords: regression, regressionwindow-wanted
I've found a regression range for these crashes in mozilla-central nightlies.  Chris, could you also test this?

firefox-2014-07-30-03-02-01-mozilla-central
firefox-2014-07-31-03-02-06-mozilla-central

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f61a27b00e05&tochange=005424a764da

So this bug shares a regression range with bug 1055694, which was ultimately caused by running out of stack space (see bug 1055694 comment #61 and bug 1062596).  But the stack space issue was fixed at bug 1062596 without fixing this bug, so the relation with this bug may be very tenuous.

In any case, though, I suspect this bug was triggered by something at bug 941296.  I'll try to hg bisect to find out exactly what.

Note that even if we triggered this bug, it may still be mostly (or even entirely) an Adobe bug.  Someone should test if the crashes are reproducible with earlier Flash versions.  I've been testing with 17.0.0.134, which I think is the current version.
There's another even uglier possibility:

The following patch is also in the regression range, which triggered bug 1134027:

 Bug 1045128 - Bump MacOS X SDK to 10.7 for release builds. r=ted
author	Ralph Giles <giles@mozilla.com>
	Mon, 28 Jul 2014 10:36:52 -0700

I'll test for this, too.
I bisected this crash to the same regression range:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f61a27b00e05&tochange=005424a764da

There are some OS X platform decoder changes in that pushlog, but they shouldn't affect Flash. There are also some changes to the OS X SDKs we use. Could that cause dynamic linking issues in the plugin sandbox?
Yup, the following patch is the trigger:

 Bug 1045128 - Bump MacOS X SDK to 10.7 for release builds. r=ted
author	Ralph Giles <giles@mozilla.com>
	Mon, 28 Jul 2014 10:36:52 -0700

I tested the same way I did at bug 1134027:  By doing "hg update -r 042fa33c3f5c" (the rev just before 70935e906273) and building twice (on OS X 10.7.5) -- once with the 10.6 SDK and once with the 10.7 SDK.  The latter build (made with the 10.7 SDK) had this bug, but not the former (made with the 10.6 SDK).

As with bug 1134027, I doubt there's anything Mozilla can do about this.  It may very well be an Apple bug.  But it will probably be impossible for anyone outside of Adobe to figure out exactly what's going on.
These crashes don't happen with Flash 16.0.0.305.

As with bug 1134027, they don't happen on OS X 10.7.5, but do happen on 10.9.5 and 10.10.2 (I can't test on 10.8.5).  They happen only on a Retina display, and then only if Firefox is actually using HiDPI mode.  They happen only if Flash is using hardware acceleration.
Crash Signature: [@ glBindBufferARB ] → [@ glBindBufferARB ] [@ glDeleteTextures ]
Summary: Adobe Flash 17.0.0.134 crashing on Mac OS X 10.10.2 glBindBufferARB → Adobe Flash 17.0.0.134 crashing in Flash thread on Mac OS X 10.10.2 and 10.9.5
Crash Signature: [@ glBindBufferARB ] [@ glDeleteTextures ] → [@ glBindBufferARB ] [@ glDeleteTextures ] [@ libGL.dylib@0x9bdc ]
Crash Signature: [@ glBindBufferARB ] [@ glDeleteTextures ] [@ libGL.dylib@0x9bdc ] → [@ glBindBufferARB ] [@ glDeleteTextures ] [@ libGL.dylib@0x9bdc ] [@ libGL.dylib@0x1887 ]
Actually these crashes are also happening on OS X 10.8.5 and 10.7.5 (though I was unable to reproduce them on 10.7.5).
Crash Signature: [@ glBindBufferARB ] [@ glDeleteTextures ] [@ libGL.dylib@0x9bdc ] [@ libGL.dylib@0x1887 ] → [@ glBindBufferARB ] [@ glDeleteTextures ] [@ libGL.dylib@0x9bdc ] [@ libGL.dylib@0x1887 ] [@ libGL.dylib@0x9b01 ] [@ libGL.dylib@0x94e6 ] [@ libGL.dylib@0x1fc8 ] [@ libGL.dylib@0x81a5 ] [@ libGL.dylib@0x1c30 ] [@ libGL.dylib@0x18b5 ] [@ libGL.d…
Summary: Adobe Flash 17.0.0.134 crashing in Flash thread on Mac OS X 10.10.2 and 10.9.5 → Adobe Flash 17.0.0.134 crashing on Flash thread in libGL.dylib in FF 34 and up
This bug is the #1 Mac topcrasher for FF 37 and FF 36.  So it's really quite urgent we get it fixed.

Jeromie, you hint at bug 1134027 comment #13 that you have an easy workaround for that bug.  Do you?  And if so does it also work for this bug?  And if so is it something Adobe can get into a new Flash release quickly?

If you *don't* have an easy workaround, this bug will be very difficult to figure out, even for someone who knows Adobe's code intimately.  If that's your current situation, I might be able to help.  Or at least I can offer the following suggestion:

All through Apple's system code, calls are made to _CFExecutableLinkedOnOrAfter() to determine what version of OS X the executable was created on (which is basically equivalent to which SDK it was linked against).  The code behaves differently depending on what this method returns.

This method is undocumented, but the following declaration is available in the CF download at http://opensource.apple.com/:

extern "C" Boolean _CFExecutableLinkedOnOrAfter(CFSystemVersion version);

CFSystemVersion is an enum, which is defined as follows in Apple's most recent CF download:

typedef CF_ENUM(CFIndex, CFSystemVersion) {
    CFSystemVersionCheetah = 0,         /* 10.0 */
    CFSystemVersionPuma = 1,            /* 10.1 */
    CFSystemVersionJaguar = 2,          /* 10.2 */
    CFSystemVersionPanther = 3,         /* 10.3 */
    CFSystemVersionTiger = 4,           /* 10.4 */
    CFSystemVersionLeopard = 5,         /* 10.5 */
    CFSystemVersionSnowLeopard = 6,	/* 10.6 */
    CFSystemVersionLion = 7,		/* 10.7 */
    CFSystemVersionMountainLion = 8,    /* 10.8 */
    CFSystemVersionMax,                 /* This should bump up when new entries are added */

};

There's also the following comment in the code:

/* _CFExecutableLinkedOnOrAfter(releaseVersionName) will return YES if
   the current executable seems to be linked on or after the specified
   release. Example: If you specify CFSystemVersionPuma (10.1), you
   will get back true for executables linked on Puma or Jaguar(10.2),
   but false for those linked on Cheetah (10.0) or any of its software
   updates (10.0.x). You will also get back false for any app whose
   version info could not be figured out.

   This function caches its results, so no need to cache at call sites.

   Note that for non-MACH this function always returns true.
*/

I suspect this bug and bug 1134027 are triggered by different behavior in libGL.dylib.  Someone needs to look through that library (and possibly associated libraries), in a disassembler, for calls to _CFExecutableLinkedOnOrAfter() that might be relevant to this bug.

I can do this, though I probably won't have time for it until next week.

Of course, though, I'll only do this if Adobe doesn't already have an easy workaround.
Flags: needinfo?(jeclark)
Keywords: topcrash-mac
Another thing one can do is use interpose libraries (http://people.mozilla.org/~stmichaud/ReverseEngineering/InterposeLibraryTemplate/) to hook calls to _CFExecutableLinkedOnOrAfter() and change their return values -- individually or per-library.  So you can figure out by trial-and-error which calls to _CFExecutableLinkedOnOrAfter() might be relevant to this bug and bug 1134027.
HLS/DASH support is contributed to Flash by the PrimeTime team.  I sent the bug over there yesterday, but they haven't assigned it to an engineer yet.  I'll send a personal note conveying the impact and urgency.

Are you suggesting that moving to the 10.7 SDK is likely resolve this?
Flags: needinfo?(jeclark)
> Are you suggesting that moving to the 10.7 SDK is likely resolve this?

I'm suggesting that if you have a fix/workaround for bug 1134027, it might also work here.
The fix we're considering is moving to the 10.7 SDK.  The challenge is that it has implications for multiple browsers on Mac, so as much as we wanted to get a fix out, it wasn't something we could responsibly jump into in the final days of the endgame for our April release.

I've shared your feedback above and the additional info about the impact and urgency with the team.  As soon as I have preview builds with the 10.7 SDK, I'll be happy to share those as well if that would be useful.
> As soon as I have preview builds with the 10.7 SDK, I'll be happy to
> share those as well if that would be useful.

I think that would be very useful.

If nothing else, we could test whether or not they stop this bug's STR
from working (from causing crashes).
One thing Mozilla should consider doing here, as a temporary workaround, and if it's possible, is to turn off Flash's hardware acceleration on OS X 10.7 and up.

Do you know if there's an approved way to do this, Jeromie?  For example by adding a parameter to the <object>/<embed> tag that launches Flash?
Flags: needinfo?(jeclark)
Or some kind of NPAPI call?
If this is a solution that Mozilla feels is imperative to pursue, we'd need to have a discussion at the management level.  Please reach out through the official business channels (Jishnu, Johnny, etc) so that we can get all the right people involved.

The implications of turning off hardware acceleration extend beyond just the Flash team inside Adobe, so I can't make a recommendation there.  It *does* feel like a cure that's worse than the disease (Firefox users would lose access to a wide swath of premium video and game sites, and take a huge performance hit aross the board), even given the current crash volume.
Flags: needinfo?(jeclark)
Thanks for your response, Jeromie.

For the time being at least, I'm not going to pursue my suggestion any further (about investigating the possibility of temporarily turning off Flash hardware acceleration on OS X 10.7 and up).  Clearly it has larger implications than I first realized.

There's a distinct possibility, though, that this bug is going to make Flash basically unusable in Firefox on OS X 10.7 and up (until it's fixed).  Clearly *that*'s worse than turning off hardware acceleration :-(

Let's see how this plays out over the next week or so.
According to https://helpx.adobe.com/flash-player/kb/archived-flash-player-versions.html, Flash 16.0.0.135 (which doesn't have this bug) was released on 2015-02-05.  Jeromie, could you give us the official release date for Flash 17.0.0.134?

With this information, we can compare the crash volumes of the two versions at similar points in their release cycle.  This should give us at least a rough idea of how serious this bug is.
Flags: needinfo?(jeclark)
Yeah, I wish that the crash reporting would correctly list Mac Flash versions.  It would clear a lot of this up.  If there's something we need to do on our end to fix that, let me know and I'll get a bug open.

The Octavia release (17.0.00.134) went out on 3/12.
Flags: needinfo?(jeclark)
Oops, put the same link in twice.  Let's try this again:

Here are all the crashes in Flash 17.0.0.134 over the last week (7005):

https://crash-stats.mozilla.com/search/?platform=Mac+OS+X&plugin_version=17.0.0.134&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

And here are all the crashes in Flash 16.0.0.305 over the equivalent week in its release cycle (2942):

https://crash-stats.mozilla.com/search/?platform=Mac+OS+X&plugin_version=16.0.0.305&date=%3C%3D2015-02-27&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

So Flash 17.0.0.134 is roughly twice as crashy.  And you can see the proportion of this bug's crashes in the first link.

But I suspect that "twice as crashy" doesn't mean "unusable".
Agreed.  

I was looking at it this way: 
https://crash-stats.mozilla.com/api/SuperSearch/?product=Firefox&process_type=plugin&platform=Mac+OS+X&plugin_name=Flash&signature=~glBindBufferARB&date=%3E1%2F1%2F2015&_facets=signature&_facets=plugin_version&_facets=plugin_name&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=plugin_version&_columns=plugin_name

It looks like it's a new crash in 17.0.0.134, with at least some activity in our more recent betas.  If it's limited to Primetime and DASH, we might be able to provide some operational guidance to the major content providers (who tend to be very responsive) to attenuate the crash rate until we can land a fix in the next train.  I'll probably know more next week once someone has investigated.
The situation is roughly the same now as it was a week ago.  Over the last week, Flash 17.0.0.134 was roughly twice as crashy as Flash 16.0.0.305 over the equivalent week in its release cycle.  All of the "extra" crashes are this bug.

Crashes in Flash 17.0.0.134 over the last week (7261):

https://crash-stats.mozilla.com/search/?platform=Mac+OS+X&plugin_version=17.0.0.134&date=%3C%3D2015-04-14&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

Crashes in Flash 16.0.0.305 over the equivalent week in its release cycle (4175):

https://crash-stats.mozilla.com/search/?platform=Mac+OS+X&plugin_version=16.0.0.305&date=%3C%3D2015-03-10&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature
Flash 17.0.0.169 just came out, and I can no longer reproduce these crashes using the STR in comment #1.  But, not surprisingly, there are still lots of these crashes in the new version:

https://crash-stats.mozilla.com/search/?platform=Mac+OS+X&plugin_version=17.0.0.169&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature
I thought I had updated this bug already, apologies.  

After careful investigation, we determined that it's not actually our Primetime/DASH support.  These guys implemented their own DASH support on top of NetStream.  Analysis indicates that the crash is related to the current MacOS SDK mismatch between Firefox and Flash Player, which has spawned this new uptick in crashes.  

While we would have been happy to move in tandem with Mozilla, we unfortunately found out after the fact.  The change is somewhat risky and has implications for other browsers in the market, so it's not something we want to rush into without due diligence on the engineering side.  That said, we're investigating that effort, but I do not have an ETA at this time.
Summary: Adobe Flash 17.0.0.134 crashing on Flash thread in libGL.dylib in FF 34 and up → Adobe Flash 17.0.0.134/169 crashing on Flash thread in libGL.dylib in FF 34 and up
Do the remainder correlate to the very small subset of older Macs that shipped with an nVidia GeForce 750M? (I don't know how to pull this correlation).  That's the only config where we can reproduce this.
> There doesn't seem to be any correlation with video hardware.

Or at least not with any two or three kinds of video hardware.  And notice that there are far more crashes with Intel video hardware than with NVidia video hardware.
Actually, though, there's a reasonably strong correlation with the following 6 kinds of video hardware:

Vendor id    Device id

0x8086       0x0a2e
0x8086       0x0166
0x8086       0x0d26
0x8086       0x162b
0x10de       0x0fd5
0x10de       0x0fe9
BTW I can reproduce this bug readily on vendor id 0x8086 device id 0x161e using (appropriately) this video:

https://www.youtube.com/watch?v=OYecfV3ubP8

this particular video hardware is only found on one Mac that is not yet that common though (2015 MacBook Retina)
Note also that (as per comment #17) these crashes only happen in HiDPI mode (and only if Flash hardware acceleration is on).  That means we'll only see these crashes on machines with Retina displays, which limits them to the graphics hardware available on those machines.

I suspect these crashes aren't graphics-hardware specific, and that the dependency on HiDPI mode explains why we only see them on a limited number of kinds of video hardware.
Whoever reports that they can reproduce this bug on Flash 17.0.0.169, please also report detailed STR.  What exactly do you need to do in the video you link to to crash?
All I need to do is play the video at https://www.youtube.com/watch?v=OYecfV3ubP8 on a MacBook retina. The crash happens even before the video starts playing.
(In reply to comment #47)

Same for me.  Thanks!

I see these crashes (in FF 37.0.2, with Flash 17.0.0.169) on OS X 10.10.3 and 10.9.5 but not 10.7.5 (same as for Chris's STR from comment #1).  I only see them when Firefox HiDPI support is on and Flash hardware acceleration is on.

Jeromie, please check this particular Flash video to find out why it crashes and others don't.

I have a MacBookPro10,1.  Tony, what do you have?

Wikipedia has a good page on the hardware configurations of the different MacBook Pro models:
http://en.wikipedia.org/wiki/MacBook_Pro
URL: https://www.youtube.com/watch?v=OYecf...
Flags: needinfo?(tonyquan)
Flags: needinfo?(jeclark)
Whiteboard: [STR for Flash 17.0.0.169 in comment #47]
Here's an easy way to turn off Firefox's HiDPI support:

Right-click on an FF distro, choose Get Info, then check "Open in Low Resolution".
The trigger for this new STR is the same as for the one in comment #1 -- our switch to building with the 10.7 SDK.  See comment #16.
 I see these crashes (in FF 37.0.2, with Flash 17.0.0.169) on OS X 10.10.3 with HiDPI support on, Flash HW acceleration on and the test video I posted ( https://www.youtube.com/watch?v=OYecfV3ubP8 )  I can reproduce it on two different types of Macs that I have that have this software configuration:

MacBook (Retina, 12-inch, Early 2015):  MacBook8,1.  These will be tough to get your hands on, backordered at Apple Store 4-6 weeks right now (these are the newest MacBooks with only one USB-C port)
MacBook Pro (Retina, 13-inch, Late 2013): MacBookPro11,1

I suspect any Retina Mac running the software configuration above reproduces these crashes.
Flags: needinfo?(tonyquan)
My particular configuration is a late 2012 12-inch MacBook Pro. OSX 10.10.3, FF 37.0.2, Flash 17.0.0.169.

Graphics vendor ID: 0x8086    Device ID: 0x0166

Same problems as detailed above, happy to provide further information if needed.
> MacBook (Retina, 12-inch, Early 2015):  MacBook8,1.

You mean MacBookPro12,1, right?
Steven--nope, About this Mac -> System Report says

MacBook (Retina, 12-inch, Early 2015):  MacBook8,1

this Mac is very, very new.  It launched only on April 17th of this year so very few people have them:

http://store.apple.com/us/buy-mac/macbook

getting one of those to reproduce the problem will be a 4-6 week wait.  However, I can readily reproduce on MacBookPro11,1 as well as I mentioned above which is a much more common model.
Thanks, Tony.

So you have a 2015 "MacBook" -- a model with which I'm completely unfamiliar, and not the same as what Apple used to call the "MacBook":

http://en.wikipedia.org/wiki/MacBook

I just assumed you must have a MacBook Pro, in whose model numbering scheme the number 8,1 would indicate something that's several years old.

I don't think we need to worry about getting hold of one -- there seem to be plenty of other Apple machines on which this bug can be reproduced.
Steven--yes that's correct.  It's a new model which is something like a cross between an iPad and a MacBook Air.  wikipedia hasn't even had time to write about it yet, although it's mentioned here in the March 9, 2015 table (the link to that model goes to the MacBook article, but to a section that doesn't exist yet)

http://en.wikipedia.org/wiki/Timeline_of_Macintosh_models#2010s

It appears they numbered it MacBook8,1 because the last (previous) MacBook from 2010 was MacBook7,1.

I'm definitely willing to help out on this bug with my MacBook Pro though, of course.
We'll have a candidate fix in next week's beta.
Flags: needinfo?(jeclark)
Our testing indicates that the proposed fix does not resolve this issue on our new 5k iMac (iMac 15,1) with Firefox 37.0.2 and Flash Player 18.0.0.114.  It may be a distinct issue, but we see the same signature and are using the original STRs. 

As a workaround, disabling hardware acceleration in Flash Player does prevent the crash. 

Instructions for disabling hardware acceleration can be found in our video troubleshooting guide, here:
https://helpx.adobe.com/flash-player/kb/video-playback-issues.html
Jeromie, are you able to reproduce these crashes (on Retina Macs) with the following testcase (originally from comment #44)?

https://www.youtube.com/watch?v=OYecfV3ubP8

And if so, have you been able to identify why it crashes and other Flash videos don't?  Does it have to do with the kind of Flash video it is?
Flags: needinfo?(jeclark)
Our testing indicates that the issue was not *all* retina Macs, but only a very small window of Retina Macs that used the NVIDIA GeForce GT 750M OpenGL Engine.  We resolved that issue by blacklisting the card on Firefox.

The new 5K iMac has been a little problematic in general, so I made a point to check against it while I was in SF.  We're looking into that now.

If you're seeing this on other configs, the system reports from affected machines would be useful so that I can track down comparable machines.

Interestingly, Safari (NPAPI) and Chrome (PPAPI) are both unaffected on the same config.  If it makes sense to set up a joint troubleshooting session to understand why this is only happening on Firefox, I'm always more than happy to facilitate that.
Flags: needinfo?(jeclark)
Jeromie, what you said is incorrect for my case.  all of the Macs I reproduced the problem on so far have Intel graphics chipsets and not NVIDIA.  for example, one of the Macs I have that can reproduce it is a MacBook Pro (Retina, 13-inch, Late 2013): MacBookPro11,1

the system report clearly shows that there is only an Intel graphics card inside as shown below from the Mac system report.  Please let me know if there's any other helpful info I can provide.  I'd definitely be willing to help look at the problem.


Intel Iris:

  Chipset Model:	Intel Iris
  Type:	GPU
  Bus:	Built-In
  VRAM (Dynamic, Max):	1536 MB
  Vendor:	Intel (0x8086)
  Device ID:	0x0a2e
  Revision ID:	0x0009
  Displays:
Color LCD:
  Display Type:	Retina LCD
  Resolution:	2560 x 1600 Retina
  Retina:	Yes
  Pixel Depth:	32-Bit Color (ARGB8888)
  Main Display:	Yes
  Mirror:	Off
  Online:	Yes
  Built-In:	Yes
Flags: needinfo?(jeclark)
(In reply to Jeromie Clark from comment #60)
> Our testing indicates that the issue was not *all* retina Macs, but only a
> very small window of Retina Macs that used the NVIDIA GeForce GT 750M OpenGL
> Engine.  We resolved that issue by blacklisting the card on Firefox.
> 
> The new 5K iMac has been a little problematic in general, so I made a point
> to check against it while I was in SF.  We're looking into that now.
> 
> If you're seeing this on other configs, the system reports from affected
> machines would be useful so that I can track down comparable machines.
> 
> Interestingly, Safari (NPAPI) and Chrome (PPAPI) are both unaffected on the
> same config.  If it makes sense to set up a joint troubleshooting session to
> understand why this is only happening on Firefox, I'm always more than happy
> to facilitate that.

I don't know if it can help, but it happens also on my MacBook Pro (Early 2013) which has a NVIDIA GeForce GT 650M; in particular, it happens on the integrated display but not on the external one (non-Retina).
Ditto, per Tony'd comment. My report:

 Chipset Model:	Intel HD Graphics 4000
  Type:	GPU
  Bus:	Built-In
  VRAM (Dynamic, Max):	1024 MB
  Vendor:	Intel (0x8086)
  Device ID:	0x0166
  Revision ID:	0x0009
  Displays:
Color LCD:
  Display Type:	Retina LCD
  Resolution:	2560 x 1600 Retina
  Retina:	Yes
  Pixel Depth:	32-Bit Color (ARGB8888)
  Main Display:	Yes
  Mirror:	Off
  Online:	Yes
  Built-In:	Yes
With regard to what video hardware these crashes happen on, also see comment #43.
For the machines where you're seeing the crash and we're not, what OS versions are you using?
Flags: needinfo?(jeclark)
Jeromie, I'm seeing it on Yosemite, latest public version (10.10.3).  I had already mentioned this in https://bugzilla.mozilla.org/show_bug.cgi?id=1146036#c51
Yes, you did.  I'm curious about the other configs that don't mention the OS version.  I'm trying to figure out why we're not seeing this.  My guess is that we have a variety of hardware on a variety of OS versions and that this issue is specific to Yosemite, but I don't want to assume.
Oops, the link from comment #68 is misleading.  I'll post a better one.
Here's my most recent crash report. As stated before, I'm running OSX 10.10.3.

https://crash-stats.mozilla.com/report/index/1ec6ab49-cf5e-40c3-b4ba-17a362150506
I'm running 10.10.3 using an integrated Intel graphics chip:

Intel Iris:

  Chipset Model:	Intel Iris
  Type:	GPU
  Bus:	Built-In
  VRAM (Dynamic, Max):	1536 MB
  Vendor:	Intel (0x8086)
  Device ID:	0x0a2e
  Revision ID:	0x0009
  Displays:
Color LCD:
  Display Type:	Retina LCD
  Resolution:	2560 x 1600 Retina
  Retina:	Yes
  Pixel Depth:	32-Bit Color (ARGB8888)
  Main Display:	Yes
  Mirror:	Off
  Online:	Yes
  Built-In:	Yes
ASUS VS247:
  Resolution:	1920 x 1080 @ 60 Hz
  Pixel Depth:	32-Bit Color (ARGB8888)
  Display Serial Number:	C9LMTF017038
  Mirror:	Off
  Online:	Yes
  Rotation:	Supported

I can also confirm that the crash only occurs on my integrated Retina screen. When the video starts on my external monitor, the crash does not occur.
since Firefox 38 has now implemented Media Source Extensions for YouTube on the Mac, the YouTube testcases in this bug won't trigger the issue anymore, as those are now going to play with the HTML5 player rather than Flash.
the video in comment #1 can still reproduce the crash for me though (just seek ahead a few times until flash crashes)

http://www.dash-player.com/demo/streaming-server-and-encoder-support/?mpd=http%3A%2F%2Fbitcdn-global.bitmovin.com%2Fcontent%2Fsintel%2Fsintel.mpd
any progress here?  it's still trivially easy to reproduce the bug.
I can still reproduce this Flash crash, but only when playing the video on my MBP's integrated Retina display.

I am running Firefox 38 and OS X 10.10.3 (14D136) on a MacBook Pro (Retina, 13-inch, Late 2013) with an Intel Iris 1536 MB GPU.
There's a candidate fix in Flash Player 18.0.0.130 and higher, so this week's beta should have it.  They usually get posted Tuesday/Wednesday.

http://www.adobe.com/go/flashplayerbeta/
I tried the latest Flash Player beta (version 18.0.0.144) with Firefox 38.0.1 on a Mac that consistently reproduced the crash with the comment #1 video.  The beta version seems to have fixed the crash.
Adobe Flash Player 18.0.0.160 was released to production today.  Tested it with Firefox 38.0.5 and the crash does not reproduce. I believe the bug can be closed at this point.
Thanks, Tony. I tested Adobe Flash Player 18.0.0.160 in Firefox Nightly 41 and I can no longer reproduce the crash.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Product: External Software Affecting Firefox → External Software Affecting Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.