Flash Plugin in crashing with the 'sad-face' Build ranges: 20110819064720 79399ce1a1fb good 20110819113340 427f162c761c bad Flash: 10.3.183.5 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110819 Firefox/9.0a1 There are several patches in the range, but appears some of them didn't build on win32 - making finding the exact patch hard for me to locate. At least there is a starting range.
With the bad cset as noted above, turning 'off' dom.ipc.plugins.enabled will crash the browser on start-up if a tab has flash-content. crash-report will be no use since its not a nightly build.
Seems like one of the merges yesterday (8/21) made things worse. I get infinitely reproducible crashes on http://cnn.com using flash 11 beta 2. While other sites using flash seem unaffected. Previous to 8/21, I wasn't experiencing any crashes.
I am using Flash 126.96.36.199. (I am not sure which level of beta it is (2 or 3).) plugin-container.exe crashes with a minute or so of starting the browser and definitely if I have logged into gmail.
(In reply to Ray Murphy (WildcatRay) from comment #4) > I am using Flash 188.8.131.52. (I am not sure which level of beta it is (2 or > 3).) > > plugin-container.exe crashes with a minute or so of starting the browser and > definitely if I have logged into gmail. (Sorry. Hit the save button too quickly.) Need to add that this is with a brand new profile. Also, I think thess are a couple of crash reports for this issue: https://crash-stats.mozilla.com/report/index/bp-7e3644ec-f641-4f5f-8c9a-573cf2110822 https://crash-stats.mozilla.com/report/index/bp-65f50453-f595-4d42-9662-a97472110822
Some more crash report: https://crash-stats.mozilla.com/report/index/bp-25b4a212-950e-43a7-b7be-b2da02110822
Mozilla/5.0 (Windows NT 6.1; rv:9.0a1) Gecko/20110822 Firefox/9.0a1 ID:20110822030805 crash with OOPP for Flash disabled. dom.ipc.plugins.enabled;true dom.ipc.plugins.enabled.npswf32.dll;false https://crash-stats.mozilla.com/report/index/bp-842cc175-be92-432e-8475-5941f2110822
(In reply to pal-moz from comment #7) > Mozilla/5.0 (Windows NT 6.1; rv:9.0a1) Gecko/20110822 Firefox/9.0a1 > ID:20110822030805 > > crash with OOPP for Flash disabled. > dom.ipc.plugins.enabled;true > dom.ipc.plugins.enabled.npswf32.dll;false > > https://crash-stats.mozilla.com/report/index/bp-842cc175-be92-432e-8475- > 5941f2110822 Flash : 10.3.183.5
Would [@ ZwFindAtom ] be akin to [@ InternalFindAtom ]? That is the crash signature on my first crash report listed above Comment 5.
Looks like it, adding that to the signatures.
Seems like gmail is reliably insta-crashing on my machine today.
VStudio did much better with my crash stack than breakpad did. Here's the stack: ntdll.dll!_NtRaiseException@12() + 0x12 bytes ntdll.dll!_NtRaiseException@12() + 0x12 bytes kernel32.dll!_InternalFindAtom@12() + 0x38 bytes kernel32.dll!_GlobalFindAtomW@4() + 0x11 bytes user32.dll!_GetPropW@8() + 0xaf72 bytes xul.dll!mozilla::plugins::PluginInstanceChild::SetWindowLongHookCheck(HWND__ * hWnd, int nIndex, long newLong) Line 1400 + 0x1b bytes C++ xul.dll!mozilla::plugins::PluginInstanceChild::SetWindowLongAHook(HWND__ * hWnd, int nIndex, long newLong) Line 1418 + 0x11 bytes C++ xul.dll!mozilla::plugins::PluginInstanceChild::SetWindowLongAHook(HWND__ * hWnd, int nIndex, long newLong) Line 1419 + 0xb bytes C++ xul.dll!mozilla::plugins::PluginInstanceChild::SetWindowLongAHook(HWND__ * hWnd, int nIndex, long newLong) Line 1419 + 0xb bytes C++ ... Looks like PluginInstanceChild::SetWindowLongAHook is recursing until it runs out of stack space.
Given that bug 653361 is in the regression range and it messed with our DLL hook I'm betting that it's the cause. Nothing else really stands out.
That seems believable.
This is being reported a bunch on Input - http://input.mozilla.com/en-US/?product=firefox&version=9.0a1&date_start=2011-08-21
In local built(m-i repo.), built from be9c15f7dd33: crashes built from 33000157292b: works Triggered by: be9c15f7dd33 Makoto Kato — Bug 653361 - Dll Block list doesn't work when Avast! Anti-Virus is installed. r=vlad
(In reply to Alice0775 White from comment #19) Woo, thanks!
ooh, back that bad-boy out and re-spin nightly ? maybe ? please ?
Backed out bug 653361, we can resolve this once we have some successful result I guess?
(In reply to ben turner [:bent] from comment #23) > Backed out bug 653361, we can resolve this once we have some successful > result I guess? Although presumably there is a gap in test coverage, that this bug can be morphed into fixing maybe?
Pushed a nightly respin for the backout too.
Respin Nightly is out and appears to be running OK.
This was actually visible in tests, crashing in probably more than half of the Win7 tp runs, but perhaps because it was mistakenly turning them purple rather than red, we just ignored them.
Might this Flash crash I got on Ubuntu be related? https://crash-stats.mozilla.com/report/index/bp-854687aa-678a-4609-9db3-684cb2110822 Shall I file a new bug for this?
(In reply to alex_mayorga from comment #29) > Shall I file a new bug for this? I don't believe so, since your crash happened on build ID 20110819104536, which was before bug 653361 was backed out (ie the problem should now be fixed).
This was definitely Windows only. If you're seeing problems on Linux it's something else.
this has returned in today's nightly build based on cset: http://hg.mozilla.org/mozilla-central/rev/ce43a8644bc0 Flash crash: https://crash-stats.mozilla.com/report/index/95560fd3-4886-4963-a201-e96ea2110902 YouTube vids will not play, remain blank. No crash there, just does not play. [@ InternalFindAtom ]
We're tracking that in Bug 684215.