This is a generic bug covering the Flash 11.3 signature F1398665248_____________________________. If you have specific steps to reproduce a Flash crash, please do not comment in this bug! Instead, please file a *new* bug and mark it blocking this one.
The F1398665248_____________________________ signature in Flash crashes is a generic signature. It happens when Flash protected mode for Firefox is enabled and one of the other FlashPlayerPlugin processes crashes or is killed. Currently in Firefox 13 and 14, we only track crashes in the plugin-container process, so almost all Flash 11.3 crashes show up as this signature.
In Firefox 15 and 16 we have implemented crash reporting for the FlashPlayerPlugin processes as well, so this signature will usually not be reported; we'll see the more interesting crash signature in the Flash process instead.
It appears that this crash is uncontrolled behavior, and Adobe is working with us to make the behavior more controlled when the Flash process crashes, something like MOZ_CRASH, so this signature will very likely change in future versions of Flash 11.3.
I can confirm that with the 11.3.300.267 build killing a FlashPlayerPlugin process while hulu is running produces a different (controlled) EXCEPTION_BREAKPOINT report.
Has it been tried with Flash 11.3.300.268?
(In reply to Arthur K. from comment #2)
> Has it been tried with Flash 11.3.300.268?
It's a generic bug, so there are no STR to test
Well actually, you can usually reproduce the generic bug by playing a hulu.com movie (vimeo would probably work as well) and then killing one of the FlashPlayerPlugin.exe processes in the task manager.
Any improvement with 11.4.402.265?
(In reply to Arthur K. from comment #5)
> Any improvement with 11.4.402.265?
No. See https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&reason_type=contains&process_type=plugin&plugin_field=filename&plugin_query_type=exact&plugin_query=NPSWF32_11_4_402_265.dll&do_query=1&signature=F1398665248_____________________________
We implemented the suggested fix, similar to what is in MOZ_CRASH, for 11.3 and 11.4.402.265.
When we detect an error that requires us to shut down plugin-container, we do the following to exit the process:
This is based on the MOZ_CRASH macro defined in http://mxr.mozilla.org/mozilla-central/source/mfbt/Assertions.h#153
Is there something else we should be doing to more cleanly exit the plugin-container process when we detect a fatal error so that this is not classified as a crash for this process?
I'm not sure what you mean... we now see that the crash reason is correct (EXCEPTION_BREAKPOINT) and we can track the volume in a useful way, so I believe that the current behavior is as expected.
Ah, perhaps there was a misunderstanding then. This bug/signature was in one of the top crashers lists we were looking at, so we thought that we still needed to do something to address it.
However, if this is behaving as expected, then I suppose we will just continue to see this crash as long as we still have other crashes that cause the sandbox process to go away unexpectedly.
Yes. To the user it still represents "Flash player crashing", but to us it indicates that there was a problem in one of the other processes which was not caught usefully by the crash reporter and so what's left is a bucket of crashes which are good for volume measurements but often aren't useful in terms of engineering.
If we have new bugs with STR to reproduce this signature, I'd like to see them because I'd like to figure out why the crash reporter didn't catch the other process dying.
*** Bug 790153 has been marked as a duplicate of this bug. ***
Any improvement with 11.5.500.80?
FWIW, friend who'd encountered crasher (11.3 and 11.4 Flash in Windows 7) reports that the fix for him was disabling acceleration in Flash.
Well, maybe more of a workaround, but given the increasingly limited utility of Flash, really more of a fix for him.
Perhaps Adobe could push out a hotfix 11.4.1 w/ acceleration disabled by default? :)
Have a second report of disabling acceleration being a workaround, also a Windows user.
@Nemo: Please attach dxdiag output for affected machines, and ideally, URLs to sites where the crash is occurring consistently. We'll attempt to build out a similar configuration and reproduce the issue. Once we're sure that the crash is related to the HW/Driver combination, we can disable GPU acceleration for that particular profile.
Welp. I asked one of 'em, but he didn't answer me, and I'm betting he isn't too interested in doing debugging for Adobe when he already has a fix. I might be able to convince him to pastebin about:support or otherwise give card info.
The other fellow I can't contact.
Created attachment 748509 [details]
dmp/extra files & dxdiag
After playing http://www.youtube.com/watch?v=NWoHju_ii4c I scrolled down the page -> crash
(In reply to MrX1980 from comment #17)
I doesn't crash for me with Flash 11.7
It's bug 772097 that spiked with Flash 11.8.
It's not this bug which a generic one but will likely be fixed along with bug 772097.
with Flash 11.8.800.94 is number one on https://crash-analysis.mozilla.com/bsmedberg/flash-topcrash-release.html
*** Bug 935493 has been marked as a duplicate of this bug. ***
Tracy noticed a crash spike across branches over the weekend.
Looking at the explosive reports list for Fx29, the number of crashes with this signature doubled in the last few days, starting on 1/31.
The last Flash update was a couple of weeks ago. Also, the version of Flash reported in the reports I looked at varied from 11.9x to the latest 22.214.171.124, so it doesn't seem to be version specific.
Perhaps a change elsewhere, like a major website?
I think one reason could be "watching Super Bowl".
Flash keeps on crashing with this error in my VS2013 builds of Fx29 on Win 8.1 x64.
Here is my latest crash report https://crash-stats.mozilla.com/report/index/9935723b-25b2-4282-819f-6c1232140226
In earlier builds around 1/11, Flash did not crash. It started somewhen between 1/12 and 1/23 (with Fx28).
*** Bug 713138 has been marked as a duplicate of this bug. ***
do not publish the email adress, I become a lot of spam.
FYI, this signature is now the #1 explosive crash in Firefox 31:
I'm not sure if that indicates a worse situation or not, and I'm not sure what the next step should be. I just thought I'd document it here in case anyone has an idea about what to do.
Unless we see this as a permanent trend that probably relates to a patch on our side, I wouldn't care about those generic Flash issues on Aurora or Nightly. And we did not see any significant increase on the other channels at this point.
I suggest you to handle seriously this bug, dont underrate it.
non expert people see the crash and they rail agaist mozilla.
FF should better handle the crash report in my opinion, even regarding the plugins. EACH crash report in the year 2014 a.Ch. should be always very useful, not only a file added in the minidump folder.
this is more important than the minimal interface develops (even if it is trendy).
I wrote what I wrote above.
Now the punishment for me:
*** Bug 1133407 has been marked as a duplicate of this bug. ***
*** Bug 1099944 has been marked as a duplicate of this bug. ***
*** Bug 761597 has been marked as a duplicate of this bug. ***
*** Bug 774092 has been marked as a duplicate of this bug. ***
*** Bug 1078000 has been marked as a duplicate of this bug. ***
Flash Player has shipped a number of changes to mitigate this as part of a recent collaborative engineering effort with Mozilla. Those changes are dependent on additional changes in Firefox, and my understanding is that we're waiting on the corresponding Firefox changes to make their way through the various stability channels at this point in time.
I can't get a clear read on whether the situation is improved looking at the data in crash-stats, but we would naturally welcome additional engineering engagements to work on this as necessary moving forward.
Aaron, in which Firefox version do or did the changes ship that Jeromie is talking about?
Jeromie, can you tell us at what time or in which Flash version your side of the improvements shipped?
(In reply to Robert Kaiser (:email@example.com) - on vacation or slow to reply until the end of June from comment #39)
> Aaron, in which Firefox version do or did the changes ship that Jeromie is
> talking about?
This signature dropped significantly in volume with the Flash release that was shipped 2015-06-24.
(In reply to Robert Kaiser (:firstname.lastname@example.org) - on vacation or slow to reply until the end of June from comment #41)
> This signature dropped significantly in volume with the Flash release that
> was shipped 2015-06-24.
Oops, sorry, probably not true, forgot for a moment that we are missing Flash symbols for the new release, so of course Flash crashes with a symbolized signature seem to have dropped.
*** Bug 1188631 has been marked as a duplicate of this bug. ***
*** Bug 1188682 has been marked as a duplicate of this bug. ***
*** Bug 1188683 has been marked as a duplicate of this bug. ***
*** Bug 1221838 has been marked as a duplicate of this bug. ***
*** Bug 1249959 has been marked as a duplicate of this bug. ***
*** Bug 1250116 has been marked as a duplicate of this bug. ***
(In reply to Yorgos from comment #51)
AdapterVendorID: 0x10de, AdapterDeviceID: 0x0fc6, AdapterSubsysID: 00000000, AdapterDriverVersion: 10.18.13.6191
Could possibly be fixed by updating to (v365.19) 10.18.13.6519 drivers.
there is something in the changelog from nvidia?
because this issue arised a lot of years ago.
Now I have 10.18.13.6519 drivers.