This bug was filed from the Socorro interface and is report bp-2f84d8df-bcc4-4699-92ca-58eaf2121101 . ============================================================= This is a new not-too-high-volume signature in Flash 11.5.500.97 and 11.5.500.104, see https://crash-stats.mozilla.com/report/list?signature=F406845520___________________________ for more reports and data.
Jeromie, since this is new can you look to see whether this is an old issue with a new signature or whether it's actually a new regression that should be fixed before 11.5 release?
This is Adobe 3357709.
Summary: Flash 11.5 crash in F406845520___________________________ → [adbe 3357709] Flash 11.5 crash in F406845520___________________________
@bakanon This is a very, very low frequency crash when you look at the aggregate usage statistics for a production release. That said, it's something we'd like to fix. The fastest way to make that happen is to figure out how to reproduce it in a lab environment. I'd recommend that you work through the following troubleshooting steps: http://helpx.adobe.com/flash-player/kb/video-playback-issues.html If the issue still happens, please start a thread over on the Using Flash Player forums, so we can troubleshoot the issue in detail with you: http://forums.adobe.com/community/flashplayer/using_flashplayer?view=discussions If the issue goes away at some point during the troubleshooting process, please post that here. It'll help narrow things down.
@Clark: flash acceleration OFF (therefore video with jumpiness!) + sandbox ON: no crash. flash acceleration ON + sandbox OFF : no crash. both on (I need flash acceleration ON) : crash. never happened until flash 11.4. 11.4 caused problems for me. Adobe poeple: they hav ealready my dxdiag.txt. now with 11.5 the XUL.exe crash on FF exit after long time activity has been resolved. No xul crash. good! but there are some crash like this. Despite the title of the topic, here http://forums.adobe.com/message/4841141#4841141 you can find some interesting crash and troubleshooting attemps. thanks.
Do you have the latest available drivers installed for your sound and graphics hardware?
Also, a copy of your dxdiag would be helpful. (Start > type "dxdiag" > choose Save All Information)
Thanks for analyzing. Thank you very much.
Also, I wouldn't call this that low on frequency, given that it's #7 with 1% of all crashes on https://crash-analysis.mozilla.com/rkaiser/2012-11-11/2012-11-11.firefox.flash.11-5-502-110.html - and the top items are mostly not actionable in their current form (as you know, bsmedberg is working on getting better analysis for the hang stuff).
Am I misunderstanding the crash reporting data? I'm under the impression that we're talking about 269 recorded instances (2690, if we factor in the 10% throttling) across the 183,322,256 active daily user sessions recorded on Active Firefox versions yesterday. https://crash-stats.mozilla.com/daily?p=Firefox&v= Am I correct in thinking that for the average Firefox user, we're talking about a 0.0015% chance of encountering this crash signature per user session?
(In reply to Jeromie Clark from comment #11) > I'm under the impression that we're talking about 269 recorded instances > (2690, if we factor in the 10% throttling) across the 183,322,256 active > daily user sessions recorded on Active Firefox versions yesterday. Not sure where you get 183M from. I see ~80M ADU ("active daily users", which is a bit of a misnomer) for 16.0.2 on the 11th (which is the day matching my report linked in comment #10) - And, BTW, this is not sessions, this is Firefox installations reporting in, as every installation sends the ping we measure once a day if it's active (and idle). My report covers all versions, though, and given that release is being throttled and other channels not, it's not straight forward to come up with a matching "ADU" number (or "ADI" as we try calling it nowadays, being "installations" instead of "users"). It's true that 202 processed crashes in a day sounds low, but in my job for Mozilla as "Crash Scene Investigator" as I like to put it, I found that fixing exactly that kind of crash that covers ~1% of all crashes encountered (with this Flash version in this case) is usually the best avenue we have if it's a recent regression (therefore easier to pinpoint to a code change) and from code inspection it looks pretty defined in what's going wrong - esp. if the higher-volume crashes are not actionable because they are generic places and hard to diagnose. From that POV, still bug 810797 is a higher-profile target as it's also a recent regression, but this one is next in line - as long as analysis of the generic signatures on top of the list doesn't bring anything actionable forward. Also, given that even 11.4 (and it looks like 11.5 is going to the same overall volume again) still is by significant factors more crashy than 11.2, and already back then people were complaining that the frequency of Flash crashes is a pain, I think every crash signature in the top 10 of a given Flash version should be important to work on and get fixed. Maybe some of the not-so-high-volume ones even manage to give you a lead into what could be involved in the really bad high-volume ones.
Gotcha. I was looking at a 11-11-2012 - 11-12-2012 thinking it was a 24-hour span, not a 48-hour span, and including the Mac and Linux numbers. So let's go worst-case scenario and assume they're all in the release channel and throttled at 10%. Given 2020 crashes over 80,000,000 ADUs, we're looking at an 0.0025% (1 in 40,000) chance that a Windows Firefox user would encounter this crash in any 24-hour period. While we're very much interested in fixing all crashes in the product, I stand by my low reproducibility assessment. If my odds of hitting it were 1/200, I'd sit here for a day and bang on it with a debugger attached until it happened. When my odds of reproducing the issue are 1 in 40k, that's prohibitively difficult, and as you've pointed out, we have bigger fish to fry. Unfortunately, like the other long-running issues we're tracking, there is no reproducible case. The challenge in this particular case, is that with no reproducible steps and such a low chance of hitting the problem in lab conditions, there's not a lot of action to be taken. We're very much looking forward to the enhanced crash reporting in production Firefox releases. In the meantime, I think we're already doing everything we can to make forward progress on this. We'll continue to engage with customers via our forums to try and glean additional data that might help us narrow things down, and we'll continue to monitor the bug for new, useful information. I hope you find this acceptable.
You're basically telling me that filing bugs for recent regressions in crash data is useless unless it overshadows the unactionable crashes we have at the top positions. This is OK, but it just makes me accept that Flash will never be even nearly stable, at least from my POV.
OS: Windows NT → Windows 7
Whiteboard: [Flash 11.5]
Version: unspecified → 11.x
This crash is, of course, rising significantly in volume as the 11.5 series that introduced it is being adopted by more and more people.
The bug is (and has been) open to a developer for investigation.
(In reply to Jeromie Clark from comment #13) > Gotcha. I was looking at a 11-11-2012 - 11-12-2012 thinking it was a > 24-hour span, not a 48-hour span, and including the Mac and Linux numbers. > > So let's go worst-case scenario and assume they're all in the release > channel and throttled at 10%. Given 2020 crashes over 80,000,000 ADUs, > we're looking at an 0.0025% (1 in 40,000) chance that a Windows Firefox user > would encounter this crash in any 24-hour period. > > While we're very much interested in fixing all crashes in the product, I > stand by my low reproducibility assessment. If my odds of hitting it were > 1/200, I'd sit here for a day and bang on it with a debugger attached until > it happened. When my odds of reproducing the issue are 1 in 40k, that's > prohibitively difficult, and as you've pointed out, we have bigger fish to > fry. Unfortunately, like the other long-running issues we're tracking, there > is no reproducible case. > > The challenge in this particular case, is that with no reproducible steps > and such a low chance of hitting the problem in lab conditions, there's not > a lot of action to be taken. > > We're very much looking forward to the enhanced crash reporting in > production Firefox releases. > > In the meantime, I think we're already doing everything we can to make > forward progress on this. We'll continue to engage with customers via our > forums to try and glean additional data that might help us narrow things > down, and we'll continue to monitor the bug for new, useful information. > > I hope you find this acceptable. The issue is that the numbers for bug defects that are being reported and not everyone allows this to happen. I know that we at home get around 30+ Adobe Flash crashes a month - and that the Crash Reporter rarely if ever gets actioned.
(In reply to Nigel from comment #17) > I know that we at home get around 30+ Adobe Flash crashes a month - and that the > Crash Reporter rarely if ever gets actioned. In order to not saturate Mozilla's crash server, crashes are throttled with a 10%-ratio. Its ranking is the same whatever the throttle.
One thing that got lost in this unfortunately slightly heated argument between Jeromie and me was that those numbers were from the Flash beta version, and now that the same Flash series has been released, the numbers go up significantly.
Another flash 11.5 crash here ;) https://crash-stats.mozilla.com/report/index/c5336be1-25bb-4d73-900b-65b452121123
I hope that the report of FF17 (not 16) is now -as promised- "more readable and more helpful" in understanding and reproducing the crash. Thank you.
(In reply to candaules from comment #21) > I hope that the report of FF17 (not 16) is now -as promised- "more readable > and more helpful" in understanding and reproducing the crash. Thank you. Plugin hang reports will be more useful in 18.0 but plugin crash reports are not actionable by Mozilla. Compare the crashing thread in the report of comment 0 and comment 20. They are the same. As the Flash code analysis doesn't give a lead to fix this crash, only reliable steps to reproduce can help.
no reliable steps at the moment. this is the bad. yesterday the same usage of ff and flash and NO crash. a few days ago a very intensive usage of flash no crash, even with more than 10 tabs. the crash number increased AFETR 11.3, i.e. starting from 11.4. the strange thing about this crash: all the videos continued working, no grey screen with "send a report" and no need to reload them! perhaps a "silent crash".
(In reply to Scoobidiver from comment #22) > Plugin hang reports will be more useful in 18.0 but plugin crash reports are > not actionable by Mozilla. Compare the crashing thread in the report of > comment 0 and comment 20. They are the same. It's Flash crashing. Internals of Flash will never be "actionable by Mozilla", but we are trying hard to help our friends at Adobe to make them actionable on their side. In the case here, it of course eludes us what code inspection (which IMHO should be the first step in such a case) could show or not, only Adobe can know about that. We know it's a regression that was introduced in 11.5.500.97 (Flash beta channel), as the signature wasn't around before that version went public, and it exists in every 11.5 version since, including release (and the absolute numbers of this are rising in parallel to that getting more and more adoption). If that fact also doesn't help, then only a good reproducible case can help, but as we (you probably as much as me and others) know from our experience in crash analysis, steps to reproduce are often hard to come by, unfortunately. > As the Flash code analysis doesn't give a lead to fix this crash How do you know?
(In reply to Robert Kaiser (:email@example.com) from comment #24) > > As the Flash code analysis doesn't give a lead to fix this crash > How do you know? Probably because of: (Jeromie Clark wrote in comment #13) > In the meantime, I think we're already doing everything we can to make > forward progress on this.
Hi. I was wrong. XUL.exe crash on FF exit (!) with flash 11.5, sandbox on (!), happnes again!! also 11.5 dont resolved this crash! zero crash reports. I am sure that there are already a buzilla related to this XUL.exe crash on FF exit, starting from flash 11.3 + ff 15, I guess. I dont find it now. Nome evento problema: APPCRASH Nome applicazione: firefox.exe Versione applicazione: 188.8.131.5206 Timestamp applicazione: 50ab1ea3 Nome modulo con errori: xul.dll Versione modulo con errori: 184.108.40.20606 Timestamp modulo con errori: 50ab1df0 Codice eccezione: c0000005 Offset eccezione: 000d0148 Versione SO: 6.0.6002.2.2.0.768.3 ID impostazioni locali: 1040 Informazioni aggiuntive 1: 40d4 Ulteriori informazioni 2: 4062ad41ec8067256aa4c5e2b56d3c79 Ulteriori informazioni 3: 40d4 Ulteriori informazioni 4: 4062ad41ec8067256aa4c5e2b56d3c79 this is, I guess, a different kind of crash, that happens often, therfore I guess that it is reproducible. this happens only with => flash acceleration ON, => + sandbox ON, on FF exit. no crash if I set OFF (either in the acceleration OR in the sandbox). so I have two kind of crash, while until 11.3 I NEVER had a crash!!! please if you find the bug regariding XUL.exe you may want to update ot, thanks. perhaps this is more important than the previous crash, because here is FF crashing, even with NO effects, i.e. re-opening FF, all is ok, as none crash were happened! that's all at the moment ;)
(In reply to banakon from comment #26) > this is, I guess, a different kind of crash, that happens often, therfore I > guess that it is reproducible. If you don't crash with the F406845520 crash signature, please file a new bug.
/OT ok, I will ask to a "more expert" http://forums.mozillazine.org/viewtopic.php?f=38&t=2612567&p=12478283 to file a bug on bugzilla about this xul.exe that becomes more and more widespread and strongly related to the minidump folder in the profile. (alwayes related to the flash sandbox). /OT
by simply opening a new YT tab (the fourth YT tab), clean and new FF profile. https://crash-stats.mozilla.com/report/index/744284e2-483b-4f98-9435-656682121126
(In reply to banakon from comment #29) > by simply opening a new YT tab (the fourth YT tab), clean and new FF profile. > https://crash-stats.mozilla.com/report/index/744284e2-483b-4f98-9435- > 656682121126 I can't reproduce. Does it happen if you disable Pivot Software?
Ok I was sure that the report were unuseful in reproducing the crash. What is pivot sw, how to disable it? if you are askink about the flash acceleration, yes, disabling it (OR the sandbox) you dont become crash. Out of curiosity: what is the purpose of the crash report? why it has been implemented in firefox, if always unuseful? this is only out of curiosity ;) thanks.
(In reply to banakon from comment #31) > What is pivot sw, how to disable it? Your report shows a Winphook.dll loaded which seems to belong to it. > if you are askink about the flash acceleration, yes, disabling it (OR the > sandbox) you dont become crash. Please update your graphics drivers, you version dates from May 2012: http://www.nvidia.com/object/win8-win7-winvista-32bit-306.97-whql-driver.html
Thanks for your reply. winphook.dll: I saw that this has been installed 2007, when my PC was born. The file is not updated from nvidia, since the date is februar 2007. therefore I posted above the dxdiag. But I dont know why this file was ok (not involved in crashes) until flash 11.3 on the same machine...I am reading the long changelog form nvidia (PDF), but they are speaking about Batman and Assassin (amelioraments for newer gpu card only)... perhaps flash 11.4 did introduce some change that are conflicting with this dll that belong to the OS....
As we build out new capabilities for the next generation of online gaming, we're taking advantage of hardware acceleration on your system, where it's available. This lowers power requirements and general load on your CPU, but it also exposes latent compatibility issues with some older hardware and drivers. Flash Player 11.4 also introduced the low-latency audio feature, which moves from the older Windows WAVAudio APIs to the more modern CoreAudio APIs. Again, we're getting performance gains by using the hardware available on your system, but this may expose latent hardware/driver issues on some systems. Where we can find hardware/driver combinations that consistently display stability problems, we can blacklist them and they'll return to the older CPU-based rendering. Over the long term, we collect the data, attempt to reproduce the problem, and blacklist cards where necessary. To-date, this list is pretty short. In the meantime, we're recommend that you upgrade to the latest drivers for your video and audio cards, and see if the stability issue improves. Also, the bug remains open and is assigned to an engineer. If we can identify a change that introduced this issue, or a potential generic fix, we'll test that out in the beta channel and verify with the Mozilla crash reporting stats, as per usual. Thanks!
Thank you for your reply and explanation. Yes, GPU acceleration (enabled) its not only important for me (CPU = 3-11% YT 1080p), it is compulsory! without acceleration I see jumpiness in the video. so it is absolutely compulsory, as the firefox acceleration is (otherwise the fonts look bad). both accelerations "on" its fine. but the acceleration in flash is "old" (10.2). Interesting the audio part, that has been modified -as you say- in flash 11.4. perhaps I can confirm this, because With 11.2, 11.3 I was fine, zero issues, even after 18 hours of strong usage. At the moment I wait for nvidia reply, to estabish if there were noticeable amelioraments for *my* gpu since may 2012. You can find the hw/driver audio configuration in the attachment above. This were useful. But the GPU rendering on my machine (from 10.2 to 11.3) was fine! now its fine too: the acceleration seems to work well, 3-11% cup at 1080p, smooth rendering. perhaps the bad effect, if correlated, its this crash + xul crash on ff exit, but its strange because other people is experiencing these issues, even if their hw is very different (Seven + newer graphic card from 2011...), I know that they still are using flash 10.3, also my situation seems "better" ;) Other people did experience audio issues with flash in the past, I didnt. (perhaps) the main thing: no issues with flash gpu acceleration since 10.2, issues (these crash which you see + XUL, -only with sandbox ENABLED! if disabled all is fine, zero minidump too!) arised installing 11.4. this is sure, I can to say this. this can to help. Thank you again for the explanation and suggestions and for giving it to the enginner, I appreciate. Ok for the new video drivers (this is easy to do for me), it will be harder for audio driver realtek: an upgrade maybe a very big risk for the OS. If I have similar reports in the future (pointing to bug 807714) I dont post them again here, you know them already. Thanks. Best regards.
It looks like this is gone from 11.6.602.137 (still at ~1% in 11.5.502.146 data), has there been a known fix on the Adobe side?
Yes, there was a candidate fix included for this issue in 11.6.602.137. Glad to hear that it's having a positive impact.
(In reply to Jeromie Clark from comment #37) > Yes, there was a candidate fix included for this issue in 11.6.602.137. > Glad to hear that it's having a positive impact. Yay! In this case, I'm marking it fixed. It can be reopened if it comes up again in the 11.6 series (otherwise a new bug is probably better).
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [Flash 11.5] → [Flash 11.5][fixed in in 11.6.602.137]
is this ameliorament (in 11.6) related to the minidumps files, generated EVERY TIME you CLOSE ff (after long time usage, ONLY after you use flash player SANDBOXED) ? this were fine!
@cadauels - We would appreciate your feedback in answering that question. Please install the latest Flash Player 11.6 beta from http://www.adobe.com/go/flashplayerbeta. If you continue to see this problem, please let us know.
february I will have time to try a beta, that you suggested. at the moment: https://crash-stats.mozilla.com/report/index/1ea1ac76-737e-4ded-b151-e486f2130121 thanks. best,
(In reply to Jeromie Clark from comment #40) > @cadauels - We would appreciate your feedback in answering that question. > Please install the latest Flash Player 11.6 beta from > http://www.adobe.com/go/flashplayerbeta. > > If you continue to see this problem, please let us know. Hi Jeromie, bad news!!! another crash xul.exe with flash 11.6 (FF19) after using youtube (2 YT tabs opened long time) and sandbox on and acceleration on [needed]. I was sure that with 11.6 this "silent" crash (FF crash folder empty or minudumps only, so NO report) could have been fully resolved. It didnt :(
please re-open the bug (XUL .exe crashes on Vista32).
This issue was fixed in Flash Player 11.6.602.111. I don't see any crash reports for this signature with versions about 11.6.602.108 in the crash reporter. Can you please add the link to your crash report to this bug?
As said, no report available. Only crash without report. therefore it is hard to resolve. see comment #26 for report please.
(In reply to banakon from comment #46) > As said, no report available. There are hundreds of Flash crash signatures. How do you know it's this one if you don't have a stack trace?
by reading this message every time I close firefox after flashusage with sandbox on, => errata corrige: with 11.5.502.149 no crash! (only minidump files added in the folder, when closign ff), with the latest 11.6 I become this message as in the past, Jeromie does know this issue because in the past I wrote to the flashplayer forum with the same "report". Jeromie did talk about some regressions.... Nome evento problema: APPCRASH Nome applicazione: firefox.exe Versione applicazione: 220.127.116.1106 Timestamp applicazione: 50ab1ea3 Nome modulo con errori: xul.dll Versione modulo con errori: 18.104.22.16806 Timestamp modulo con errori: 50ab1df0 Codice eccezione: c0000005 Offset eccezione: 000d0148 Versione SO: 6.0.6002.2.2.0.768.3 ID impostazioni locali: 1040 Informazioni aggiuntive 1: 40d4 Ulteriori informazioni 2: 4062ad41ec8067256aa4c5e2b56d3c79 Ulteriori informazioni 3: 40d4 Ulteriori informazioni 4: 4062ad41ec8067256aa4c5e2b56d3c79
Where did you get the F406845520 signature in that information?
did you read the whole topic? ok, dont care about this crash.
why flash 11.6 is so bad? 11.5 was not so bad. https://crash-stats.mozilla.com/report/index/187161e2-f411-4a3c-ba58-777ce2130221 here a "very usefull" report from FF19 "but no other UUID pair found" ff16> try ff17 with a better crash report, ff17 > try ff18 which improves the report details ff18> try ff19 its report will be more useful for developers ff19 >.....? ff230?...
http://www.youtube.com/watch?v=7Xbxsl4gcSg one tab open! insert a comment > flash crash. this happens after installing ff19. ff18: no crash.
(In reply to banakon from comment #51) > https://crash-stats.mozilla.com/report/index/187161e2-f411-4a3c-ba58- > 777ce2130221 This crash report is unrelated to this bug.
perfect. also dont worry. I like the crash.
why after a lot months, with flash 11.7.700.169 in Firefox 20.0 I become every day the XUL crash when closing firefox, after long time usage (more than 8 hours, this is important!), if I use flash with sandbox on and acceleration on? no crash report generated. only the log bottom. I guess that this issue will never end. What think you about? there are other people with issues with flash sandboxed in Firefox or all the bugs has been fixed? thanks. Regards. The log: Nome evento problema: APPCRASH Nome applicazione: firefox.exe Versione applicazione: 22.214.171.12433 Timestamp applicazione: 5152542c Nome modulo con errori: xul.dll Versione modulo con errori: 126.96.36.19933 Timestamp modulo con errori: 51525346 Codice eccezione: c0000005 Offset eccezione: 000973d8 Versione SO: 6.0.6002.2.2.0.768.3 ID impostazioni locali: 1040 Informazioni aggiuntive 1: 40d4 Ulteriori informazioni 2: 4062ad41ec8067256aa4c5e2b56d3c79 Ulteriori informazioni 3: 40d4 Ulteriori informazioni 4: 4062ad41ec8067256aa4c5e2b56d3c79
(In reply to candaules from comment #55) Type about:crashes in the location bar, click crash IDs matching a Flash crash, and scroll down to Related Bugs. If the section is empty file a new bug, if it's not and have reliable steps to reproduce comment in the related bug not this one that is fixed.
Hi. about:crashes is empty. flash 11.7: xul crash not only sometimes, but very time I close FF, now even if I use FF for a half hour. in the past only if I used FF for 8 hours. but this issue arised a long time ago, Jeromie know this. but 11.7 is bad.
>click crash IDs matching a Flash crash< sometime present, but if I clic I become nothing. also no clickable. I filled a new bug.
(In reply to candaules from comment #60) > https://crash-stats.mozilla.com/report/index/d86b1cc0-d80d-4890-8ca3- > 55ac82130421 It's an empty crash not related to this bug that is fixed.
Version and milestone values are being reset to defaults as part of product refactoring.
Version: 11.x → unspecified
You need to log in before you can comment on or make changes to this bug.