Closed Bug 1151794 Opened 7 years ago Closed 6 years ago

Win8.1 - Flash Player - [@ hang | CleanupPerAppKey ]

Categories

(Core :: Plug-ins, defect)

37 Branch
x86
Windows 8.1
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 789379
Tracking Status
firefox37 + wontfix
firefox38 + unaffected
firefox39 + unaffected
firefox40 + unaffected
firefox-esr45 --- affected
firefox-esr52 --- affected
firefox53 --- affected
firefox54 --- affected

People

(Reporter: bugs, Unassigned)

References

Details

(4 keywords)

Crash Data

Attachments

(2 files)

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 17.0.0.161 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?
Flags: needinfo?(dmajor)
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>
Flags: needinfo?(dmajor)
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 17.0.0.134 plug-in instantly (Windows 8.1).
CORRECTION: any Flash content*
Very disappointed that yesterday's Shockwave release 17.0.0.169 didn't fix this issue :(
@error, please check with Firefox Nightly.
Firefox 37.0.1 Flash 17.0.0.169 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!
Keywords: crash
Duplicate of this bug: 1143395
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Flags: needinfo?(aklotz)
Ideally yes, however there is at least one known issue with the Unity plugin (bug 1151318).
Flags: needinfo?(aklotz)
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.
Keywords: topcrash
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 17.0.0.161 or 17.0.0.169 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.
Keywords: crashhang, steps-wanted
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.
Flags: needinfo?(aklotz)
Keywords: flashplayer
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.
Flags: needinfo?(aklotz)
(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 (:kairo@mozilla.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.
Flags: needinfo?(kairo)
Too late for 37 for sure.
Depends on: 1161026
Filed bug 1161026 for the prefix addition to crash-stats.
Flags: needinfo?(kairo)
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.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate 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
25.0.0.127 	10419 	32.4%
24.0.0.221 	7680 	23.9%
24.0.0.194 	7578 	23.6%
25.0.0.148 	3200 	10.0%
24.0.0.186 	1071 	3.3%
21.0.0.242 	202 	0.6%
23.0.0.207 	126 	0.4%
22.0.0.209 	123 	0.4%
23.0.0.162 	91 	0.3%
23.0.0.205 	85 	0.3%
19.0.0.245 	69 	0.2%
21.0.0.213 	66 	0.2%
22.0.0.192 	65 	0.2%
24.0.0.189 	64 	0.2%
25.0.0.104 	59 	0.2%
25.0.0.119 	58 	0.2%
Version: unspecified → 37 Branch
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.