Closed
Bug 680862
Opened 13 years ago
Closed 13 years ago
Flash plugin crashes
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(firefox9-)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox9 | - | --- |
People
(Reporter: jmjjeffery, Unassigned)
References
Details
(Keywords: regression)
Crash Data
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.
Reporter | ||
Updated•13 years ago
|
Keywords: regression
Reporter | ||
Comment 1•13 years ago
|
||
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.
Comment 2•13 years ago
|
||
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=79399ce1a1fb&tochange=427f162c761c
Updated•13 years ago
|
Keywords: regressionwindow-wanted
Hardware: x86_64 → x86
Comment 3•13 years ago
|
||
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.
Comment 4•13 years ago
|
||
I am using Flash 11.0.1.98. (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.
Comment 5•13 years ago
|
||
(In reply to Ray Murphy (WildcatRay) from comment #4) > I am using Flash 11.0.1.98. (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
Comment 6•13 years ago
|
||
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
Updated•13 years ago
|
Crash Signature: [@ InternalFindAtom ]
Comment 11•13 years ago
|
||
Would [@ ZwFindAtom ] be akin to [@ InternalFindAtom ]? That is the crash signature on my first crash report listed above Comment 5.
Comment 12•13 years ago
|
||
Looks like it, adding that to the signatures.
Crash Signature: [@ InternalFindAtom ] → [@ InternalFindAtom ]
[@ ZwFindAtom ]
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.
Comment 17•13 years ago
|
||
This is being reported a bunch on Input - http://input.mozilla.com/en-US/?product=firefox&version=9.0a1&date_start=2011-08-21
Comment 18•13 years ago
|
||
Sorry, better query: http://input.mozilla.com/en-US/?product=firefox&version=9.0a1&date_start=2011-08-21&q=flash
Comment 19•13 years ago
|
||
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
Updated•13 years ago
|
Blocks: 653361
tracking-firefox9:
--- → ?
Updated•13 years ago
|
Keywords: regressionwindow-wanted
(In reply to Alice0775 White from comment #19) Woo, thanks!
Reporter | ||
Comment 21•13 years ago
|
||
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?
Comment 24•13 years ago
|
||
(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.
Comment 27•13 years ago
|
||
Respin Nightly is out and appears to be running OK.
Comment 28•13 years ago
|
||
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.
Comment 29•13 years ago
|
||
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?
Comment 30•13 years ago
|
||
(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.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Crash Signature: [@ InternalFindAtom ]
[@ ZwFindAtom ] → [@ InternalFindAtom ]
[@ ZwFindAtom ]
[@ _SEH_prolog ]
[@ _SEH_prolog4 ]
[@ mozilla::plugins::PluginInstanceChild::SetWindowLongHookCheck(HWND__*, int, long) ]
[@ mozilla::plugins::PluginInstanceChild::SetWindowLongWHook(HWND__*, int, long) ]
Reporter | ||
Comment 32•13 years ago
|
||
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 ]
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
We're tracking that in Bug 684215.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•