Status

()

Core
Plug-ins
--
critical
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: Jim Jeffery not reading bug-mail 1/2/11, Unassigned)

Tracking

({regression})

Trunk
x86
Windows 7
regression
Points:
---

Firefox Tracking Flags

(firefox9-)

Details

(crash signature)

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.
Keywords: regression
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

6 years ago
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=79399ce1a1fb&tochange=427f162c761c

Updated

6 years ago
Keywords: regressionwindow-wanted
Hardware: x86_64 → x86

Comment 3

6 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

6 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

6 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

6 years ago
Some more crash report:

https://crash-stats.mozilla.com/report/index/bp-25b4a212-950e-43a7-b7be-b2da02110822

Comment 7

6 years ago
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

Comment 8

6 years ago
(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

Comment 9

6 years ago
More crash;

https://crash-stats.mozilla.com/report/index/bp-7b162adf-e018-4838-a1c6-33f0c2110822

Updated

6 years ago
Duplicate of this bug: 680853

Updated

6 years ago
Crash Signature: [@ InternalFindAtom ]

Comment 11

6 years ago
Would [@ ZwFindAtom ] be akin to [@ InternalFindAtom ]? That is the crash signature on my first crash report listed above Comment 5.

Comment 12

6 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.
This is being reported a bunch on Input - http://input.mozilla.com/en-US/?product=firefox&version=9.0a1&date_start=2011-08-21
Sorry, better query: http://input.mozilla.com/en-US/?product=firefox&version=9.0a1&date_start=2011-08-21&q=flash

Comment 19

6 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

6 years ago
Blocks: 653361
tracking-firefox9: --- → ?

Updated

6 years ago
Keywords: regressionwindow-wanted
(In reply to Alice0775 White from comment #19)

Woo, thanks!
ooh, back that bad-boy out and re-spin nightly ?  maybe ? please ?
Duplicate of this bug: 680942
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.
Duplicate of this bug: 681051

Comment 27

6 years ago
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.

Comment 29

6 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?
(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
Last Resolved: 6 years ago
Resolution: --- → FIXED

Updated

6 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) ]
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
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED

Updated

6 years ago
tracking-firefox9: ? → -
You need to log in before you can comment on or make changes to this bug.