Closed Bug 1151794 Opened 8 years ago Closed 8 years ago
.1 - Flash Player - [@ hang | Cleanup Per App Key ]
About 17000 crashes in 7 days (Windows 8.1 only): https://crash-stats.mozilla.com/report/list?product=Firefox&signature=hang+%7C+CleanupPerAppKey https://forums.adobe.com/message/7101350#7101350 Microsoft bug? Because I see nearly all Firefox and Flash Player Versions. Also the graphic adapters from Intel, AMD and nVidia.
Comments: * PLEASE TELL ME THAT WHEN I ACCIDENTLY RIGHT CLICK MY MOUSE WHILE PLAYING MY GAME, I KEEP GETTING THIS ADOBE FLASH PLUGIN CRASH REPORT * Crashes constantly on Farmville 2. (and several more variants of the farmville theme) * This has been happening frequently since I updated my Adobe, particularly with Shutterfly.com. http://bsmedberg.github.io/socorro-toolbox/html/multiple-minidumps.html?crashID=5bcb70b9-4eb7-49cb-bc99-03bc62150331 Something is weird with the stack walking: MsgWaitForMultipleObjectsEx has the extra "CleanupPerAppKey" frame which I'm pretty sure is a red herring.
This is ADBE 3835579. This is fixed in Flash Player 188.8.131.52 and higher as part of the collaborative effort between Mozilla and Adobe to address this class of hangs. Additional changes are required (and underway) from Firefox for the fix to be effective. The changes to Flash Player should land in our beta channel in the next week or two, just depending on how things land. The fix should hit the release channel in our May update. Comments from our developer follow: This fix is also dependent on changes made to Firefox. Please make sure you test with the appropriate Flash Player and Firefox versions. (The latest Firefox Nightly version should have the changes) Worked with Ben Turner and Aaron Klotz from Mozilla to identify an issue in the IPC code used by both Firefox and Flash Player Protected Mode that contributed to browser hangs. We needed to add a few additional messages related to Accessibility events to the window neutering code that we borrowed from Mozilla. In addition, Mozilla identified an issue with our failure to pump messages sent to a hidden window used by COM that could also result in hangs. Aaron and Ben wrote some code to find and track this hidden COM window so that we can also pump messages for it while we are in the middle of IPC calls, etc. These hangs may require changes from BOTH Firefox and Flash Player to be completely fixed, so please verify that you are testing with a version of Firefox that has the corresponding changes before verifying that this hang is fixed in the latest Flash Player version. The latest Firefox Nightly version should have the changes.
I have tested today with Flash Player 17,0,0,134 and Firefox 37.0.1 on Windows 8.1 but crash still present so Firefox work to fix as Adobe has says is resolved for Flash.. and i will tri to install the last Firefox version because now i must use ESR for this bug in Firefox. ESR is the only version not affected.
@Marco - Please note that you're currently testing with a version of Flash that does not have the fix. You'll probably need our next beta build and Nightly to verify.
Yes you are right. I hate this issue. I hope to see soon fixxed as i read here. Thanks! Is many month with this issue. Thanks again!
dmajor, can you take a look at comment 0 and comment 1, we're trying to figure out if "CleanupPerAppKey" is just misleading? If so this is probably just the same hang we've been seeing (and hopefully we'll see it disappear once bug 1133351 makes it to release and ADBE 3835579 (see comment 2) is released). If not maybe it's a new regression?
a constant crash issue that happens every time i use firefox after it first loads or computer wakes from sleep mode. any help?
(In reply to Ben Turner [:bent] (use the needinfo flag!) from comment #6) > dmajor, can you take a look at comment 0 and comment 1, we're trying to > figure out if "CleanupPerAppKey" is just misleading? If so this is probably > just the same hang we've been seeing (and hopefully we'll see it disappear > once bug 1133351 makes it to release and ADBE 3835579 (see comment 2) is > released). If not maybe it's a new regression?
I can give you guys a Flash Player nightly build if you want to play with it. I confirmed that the latest Flash Player build and Firefox Nightly fix the right-click hang yesterday.
Yeah, just ignore the line with CleanupPerAppKey. Here's what my debugger says for the main dump in comment 1: 0113db54 750c112f ntdll!NtWaitForMultipleObjects+0xc 0113dce0 76c2d433 KERNELBASE!WaitForMultipleObjectsEx+0xcc 0113dd44 769afab4 user32!MsgWaitForMultipleObjectsEx+0x163 0113dd7c 76aab50c combase!CCliModalLoop::BlockFn+0x111 <snip>
That's definitely the COM STA IPC stuff.
I have the same issue. Any Java content I right-click on from Firefox 37.01 (and earlier versions) locks up the Shockwave Flash 184.108.40.206 plug-in instantly (Windows 8.1).
CORRECTION: any Flash content*
Very disappointed that yesterday's Shockwave release 220.127.116.11 didn't fix this issue :(
@error, please check with Firefox Nightly.
Firefox 37.0.1 Flash 18.104.22.168 with the right click Flash Crash on Windows 8.1
@JeromieClark, thanks! Yes, version 40 from the Nightly site fixed the issue. Hopefully we'll see that in a GA release soon!
Works also for me, Nightly version solve the Flash Crash. I hope this will be fixxed soon in official Firefox version!
CXan someone who understands this better update the affected flags? That dupe had: status-firefox36: affected status-firefox37: affected status-firefox38: affected status-firefox39: affected status-firefox-esr31: unaffected
I'M worried to read version 39 is also affected and now we are only to version 36. I hope for all month this bug will be held valid on current last version of Firefox ESR version will be not edited to have this bug too. So for see this fixed we have to wait version 40? So other 3 or 4 month of bug? :D
(In reply to Ben Turner [:bent] (use the needinfo flag!) from comment #6) > dmajor, can you take a look at comment 0 and comment 1, we're trying to > figure out if "CleanupPerAppKey" is just misleading? If so this is probably > just the same hang we've been seeing (and hopefully we'll see it disappear > once bug 1133351 makes it to release and ADBE 3835579 (see comment 2) is > released). If not maybe it's a new regression? Can the work in bug 1133351 get uplifted? Sounds like we've fixed this on Nightly, but other release still have it.
Ideally yes, however there is at least one known issue with the Unity plugin (bug 1151318).
This is still a problem in Nightly, I'm seeing reports in the latest. This is also currently our top crasher in the plugin process.
debugger tab comes up also sometimes. i have no idea what it is or how to use it. all crashes happen when pages load that require flash - i dont have a right click issue. happens loads on facebook. one of the most frustrating issues ive had on a comuputer
I don't think this is fixed yet, currently there are 43 crashes on Nightly 40 with Flash versions 22.214.171.124 or 126.96.36.199 http://bit.ly/1P6yqtr
It would be really nice to be able to have a repro for this. The plugin container stack is similar to the other bug, but something is different here.
FWIW, someone on our forums mentioned that they're seeing fairly reproducible crashing when scrolling their facebook feed with lots of embedded SWFs, but they were hitting the generic crash using Win7. I haven't had a chance to dig into it yet. Might be worth getting a few eyes on it.
FYI - still confirmed crashing on Flash right-click in release 37.0.2
[Tracking Requested - why for this release]: This is the second largest plugin hang on Dev Edition 39 right now (after bug 1156800 but with about 2x the reports than the next one on the list), and our plugin hang rate is 5-10x what it was for previous trains.
I think this is significant enough to track 37+. We should take a fix in 38 assuming one is available before we're scheduled to release.
aklotz, does this hang look like a new signature or an old hang whose signature has changed? bsmedberg said you were investigating this bug.
I think for the moment that we need to treat it as a new one, with some caveats: 1) It's not just the "CleanupPerAppKey" signature of the top frame that uniquely identifies this case; the entire stack needs to be taken into account. 2) If you look at the spike in Aurora, given the completely different lower frames, that's a different problem than this bug. "CleanupPerAppKey" is kind of like our hangs involving MsgWaitForMultipleObjects in the sense that it is part of the signature, may provide a hint to the cause, but is not necessarily harmful itself.
(In reply to Aaron Klotz [:aklotz] (please use needinfo) from comment #34) > "CleanupPerAppKey" is kind > of like our hangs involving MsgWaitForMultipleObjects in the sense that it > is part of the signature, may provide a hint to the cause, but is not > necessarily harmful itself. If this is a generic frame, we can get it added to the prefix "skiplist", which means that the next frame is appended to the signature (with a |) - do we want that here?
(In reply to Robert Kaiser (:email@example.com) from comment #35) > (In reply to Aaron Klotz [:aklotz] (please use needinfo) from comment #34) > > "CleanupPerAppKey" is kind > > of like our hangs involving MsgWaitForMultipleObjects in the sense that it > > is part of the signature, may provide a hint to the cause, but is not > > necessarily harmful itself. > > If this is a generic frame, we can get it added to the prefix "skiplist", > which means that the next frame is appended to the signature (with a |) - do > we want that here? Yes, absolutely. This bogus frame is obfuscating all sorts of different hangs.
Filed bug 1161026 for the prefix addition to crash-stats.
Here are two crash reports after the prefix addition: https://crash-stats.mozilla.com/report/index/6fe91cf6-fbb1-4259-8b35-3cb042150508 https://crash-stats.mozilla.com/report/index/9bd1a4e1-b007-440f-8c23-c71762150508 I hope they are more informative now.
Hmm, the dreaded F_1152915508...
Crash Signature: [@ hang | CleanupPerAppKey ] → [@ hang | CleanupPerAppKey ] [@ hang | CleanupPerAppKey | MsgWaitForMultipleObjectsEx | MsgWaitForMultipleObjects | F_1152915508___________________________________ ]
And here's why I call it "dreaded": bug 789379
(In reply to MrX1980 from comment #39) > Here are two crash reports after the prefix addition: > https://crash-stats.mozilla.com/report/index/6fe91cf6-fbb1-4259-8b35- > 3cb042150508 > https://crash-stats.mozilla.com/report/index/9bd1a4e1-b007-440f-8c23- > c71762150508 > I hope they are more informative now. Has this been rolled out? If so I think we can close this bug as invalid now.
(In reply to Jim Mathies [:jimm] from comment #42) > Has this been rolled out? If so I think we can close this bug as invalid now. The prefix has been rolled out, yes. That doesn't automatically make the bug invalid if we have steps to reproduce this. If not, it's still not invalid but a dupe of bug 789379.
I'm unclear whether we should mark this unaffected or wontfix, but I need to pick one so that this will fall off my list of tracked bugs.
This bug was marked "RESOLVED" 2 years ago. However the bug was never actually resolved. There are still thousands of crashes under this crash signature on a regular basis. Should this bug be re-opened?
Signature report for hang | CleanupPerAppKey | MsgWaitForMultipleObjectsEx | MsgWaitForMultipleObjects | F_1152915508___________________________________ Showing results from 3 months ago Windows 8.1 32158 100.0% Firefox 52.0.2 1310 38.4% 1877 Firefox 53.0b99 707 20.7% 767 Firefox 53.0b9 272 8.0% 153 Firefox 53.0 230 6.7% 200 Firefox 53.0b8 207 6.1% 152 Firefox 53.0b10 111 3.3% 72 Firefox 52.0.1 105 3.1% 104 Firefox 53.0b7 63 1.8% 39 Firefox 52.0b7 55 1.6% 1 Firefox 54.0b1 55 1.6% 26 Firefox 52.1.0esr 36 1.1% 10 Firefox 52.0.2esr 35 1.0% 11 Firefox 54.0a2 25 0.7% 19 Firefox 52.0 21 0.6% 28 Firefox 53.0b6 18 0.5% 15 Firefox 51.0.1 17 0.5% 18 Firefox 45.8.0esr 11 0.3% 8 Firefox 11.0b5 10 0.3% 1 Firefox 47.0.2 9 0.3% 11 Firefox 45.9.0esr 8 0.2% 3 plugin 32158 100.0% x86 32158 100.0% Flash Version 188.8.131.52 10419 32.4% 184.108.40.206 7680 23.9% 220.127.116.11 7578 23.6% 18.104.22.168 3200 10.0% 22.214.171.124 1071 3.3% 126.96.36.199 202 0.6% 188.8.131.52 126 0.4% 184.108.40.206 123 0.4% 220.127.116.11 91 0.3% 18.104.22.168 85 0.3% 22.214.171.124 69 0.2% 126.96.36.199 66 0.2% 188.8.131.52 65 0.2% 184.108.40.206 64 0.2% 220.127.116.11 59 0.2% 18.104.22.168 58 0.2%
skywalker33 comment 43 is correct. Without steps to reproduce this is the same of and correctly marked as a duplicate of bug 789379 If you do have specific steps to reproduce, at this point it would be better to file a new bug than further confuse this one with 50 comments already.
You need to log in before you can comment on or make changes to this bug.