562186 - [adbe 2256842] browser crashes and exits every time I try to run video in full screen mode. [@ NPSWF32.dll@0x747d2]

Status: RESOLVED FIXED

(External Software Affecting Firefox Graveyard :: Flash (Adobe), defect)

Description

[Rich Fowler]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)

Every time I try to run a Flash-based video player in full-screen mode, Firefox will crash immediately to desktop. This only started happening when I was upgraded to 3.6.3 from 3.5.

Reproducible: Always

Steps to Reproduce:
1. Go to Youtube. 
2. Play a video in full-screen mode.
3. Browser crashes immediately to desktop.
Actual Results:  
Browser crashes immediately to desktop. All processes are killed.

Expected Results:  
It should have played the video normally in full-screen mode, like it did before I was upgraded.

Comment 1

[Matthias Versen [:Matti]]

Always include the used plugin version if you report a bug about a plugin like flash in this case.
And please read https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report

Comment 2

[Rich Fowler]

I'm running 10.0.45.2, the latest version of the Flash player.

Here's the only crash report I could find:
http://crash-stats.mozilla.com/report/index/bp-a5c6fe63-9f3a-4aa8-9ae4-0d0b72100418

Usually, when it crashes, it crashes immediately to desktop, and the crash reporter does NOT activate. All processes are killed.

Comment 3

[timeless]

Signature	NPSWF32.dll@0x747d2
UUID	a5c6fe63-9f3a-4aa8-9ae4-0d0b72100418
Time 	2010-04-18 22:07:23.878100
Uptime	133266
Last Crash	361882 seconds before submission
Product	Firefox
Version	3.6.3
Build ID	20100401080539
Branch	1.9.2
OS	Windows NT
OS Version	5.1.2600 Service Pack 3
CPU	x86
CPU Info	GenuineIntel family 6 model 15 stepping 2
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x33e30000
User Comments	As soon as I tried to go full-screen with the video, it crashed. In fact, it crashes every time I do it, and it only started when I upgraded to 3.6.3. Everything was fine with 3.5.9. -_-+
Processor Notes 	
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	NPSWF32.dll 	NPSWF32.dll@0x747d2 	
1 	NPSWF32.dll 	NPSWF32.dll@0x8486e 	
2 	NPSWF32.dll 	NPSWF32.dll@0x84e23 	

Show/hide other threads
Thread 0
Frame 	Module 	Signature [Expand] 	Source
0 	apphelp.dll 	SdbGrabMatchingInfo 	
1 	faultrep.dll 	StartDWException 	
2 	faultrep.dll 	ReportFault 	
3 	kernel32.dll 	UnhandledExceptionFilter 	
4 	kernel32.dll 	_seh_longjmp_unwind 	
5 	ntdll.dll 	ExecuteHandler2@20 	

NPSWF32.dll 	10.0.45.2 	EF4B0B547B3349C898B243CC64A91FF61 	NPSWF32.pdb

Comment 4

[Rich Fowler]

I couldn't catch the latest crash-- but I was watching the processes when Flash loaded, locked up, and killed everything. I was trying to maximize the video on this page:

http://news.bbc.co.uk/2/hi/europe/8653949.stm

So it's not just a youtube issue, it's a Flash issue, it seems.

Comment 5

[Jet Villegas (inactive)]

Picking this up. Can we get the PDB symbols pointed at this one too?

Comment 6

[timeless]

I think that the presence of symbols on the server /might/ mean that i won't be able to search for newer crashes w/ what would have been a given signature because the signature would be changed to a valid function :(.

Comment 7

[Jet Villegas (inactive)]

Our goal with the symbols we've provided is to ensure that crash bugs that come back 'WORKSFORME' can be verified as truly 'FIXED' in future releases. We often fix those bugs with guard code even though we could not repro the bug in-house. The symbol mapping shouldn't change from build to build, even with address-space layout changes. Sometimes, we do change class and function names in our source code and that would change the mapping, but I think it's still better for us to know that it crashed in a specific function rather than a variable pointer-offset.

Comment 8

[timeless]

yeah, but the problem is that for any crash before we got your symbol tables for which we haven't saved a .dump, we've flattened the crash into an address (and probably garbage for calling frames). For a crash in the same build which arrives after we got your symbol tables, we'll convert the stack into references relative to your symbols.

this means that i can't look at a crash from 'before' and decide if it's "gone away" because that same crash reported 'before' would have an offset relative to npswf32.dll and the crash reported 'after' will be relative to a function.

I'm not saying that what you've done is bad. just that it will be hard for us to do much w/ any of the before data. In the rare cases where we happen to have a .dmp from a crash which was processed 'before', if i can access your 'public' symbols, i can try to get a better stack trace, i think that only applies to a handful of crashes.

Comment 9

[Scoobidiver (away)]

Reporter, are you able to reproduce?
Can you provide a recent crash report?

Comment 10

[smadayag]

this may be related...  there was a fullscreen hardware acceleration crash with directX driver returning a surface pointer that was non null but invalid.  

the work around was to disable hardware acceleration.  we resolved fixed this issue in 10.1 Argo.  our internal reference bug is #2256842...

Comment 11

[Scoobidiver (away)]

(In reply to smadayag from comment #10)
> the work around was to disable hardware acceleration.  we resolved fixed
> this issue in 10.1 Argo.  our internal reference bug is #2256842...
Let's close it now.

Comment 12

[BMO Automation]

Version and milestone values are being reset to defaults as part of product refactoring.