767870 - Crash F909392315_____________________________________ F2166389_____________________________________________________________________ F_917831355____________________________________________ F1315696776________________________________ F81047063______________

Status: RESOLVED FIXED

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

Description

[Bob Clary [:bc] (inactive)]

Attachment: log

1. http://www.southparkstudios.co.uk/clips/sp_vid_412200/?tab=featured
2. Shutdown
3. Crash
F909392315_____________________________________ F2166389_____________________________________________________________________ F_917831355____________________________________________ F1315696776________________________________ F81047063_______________________________________

Beta, Aurora, Nightly Win 7. 

Repeat until you crash. 

A windbg session on Nightly showed freed heap being written as a first chance exception. Continuing execution does not hit the debugger again fwiw. Attaching the crash report, log and windbg session for your reading pleasure.

I'm not sure why these automation breakpad stacks don't relate to the windbg ones...

breakpad's exploitable rates this as medium exploitable and written heap is enough to make the ss.

Comment 1

[Bob Clary [:bc] (inactive)]

Attachment: crash report

Comment 2

[Bob Clary [:bc] (inactive)]

Attachment: windbg output

Comment 3

[Benjamin Smedberg]

673 crashes in this signature, although I expect that this is also a generic signature when the Flash sandbox processes crash. bc, are you tracking crashes in those processes as well?

Comment 4

[Bob Clary [:bc] (inactive)]

No. I'm currently dependent on minidumps being produced.

Comment 5

[Jeromie Clark]

I'm not able to repro in Firefox 13.0.1 or 15.0a2 with Flash Player 11.3.300.262 on Win7 x64.

Comment 6

[Bob Clary [:bc] (inactive)]

Jeromie, you might want to use a debug build from https://ftp.mozilla.org/pub/mozilla.org/mozilla.org/firefox/nightly/2012-06-25-mozilla-central-debug/ You will need to have the vc80 debug crt installed on your machine to run it.

I just reproduced a heap free block modified using the southpark url and today's Nightly debug build on Windows 7 64bit.

Benjamin, what options should I use to .dump to produce a useful minidump for this? I am in the plugin-container process and do not see the Flash processes at all in the process list.

Comment 8

[Bob Clary [:bc] (inactive)]

Attempting to reproduce a crash with the southpark url I finally hit an ABORT that I've seen in the past but was never able to reproduce:

###!!! ABORT: __delete__()d actor: file c:/work/mozilla/builds/nightly/mozilla/firefox-debug/ipc/ipdl/PPluginInstance.cpp, line 28

http://bclary.com/bugz/southpark-abort-delete-d-full-dumps.tar.bz2

I'll keep trying to get the other crash. Note these crashes are really unreliable to reproduce. I have to keep trying dozens of times to get a crash. Note for now I am ignoring the modified free heap block first chance exception.

Comment 9

[Bob Clary [:bc] (inactive)]

Ok, got a crash where the plugin-container and one of the FlashPlayerPlugin processes were gone, but the firefox and the other FlashPlayerPlugin processes were left. I've included dumps for each along with the windbg log. See http://bclary.com/bugz/southpark-FlashPlayerPlugin.tar.bz2

Comment 10

[Bob Clary [:bc] (inactive)]

Jeromie, if you create an issue for this can you add bclary? thanks.

Comment 11

[Jeromie Clark]

We've got an internal bug open on it (3286088), but I haven't filed a public one.  Can you give me the output from dxdiag for the machine you're reproducing this on?

Comment 12

[Bob Clary [:bc] (inactive)]

Attachment: DxDiag.txt

Comment 13

[Jeromie Clark]

We're seeing a significant decrease in the incidence of this crash signature between 11.3.300.262 and 11.3.300.265 across Firefox 13.0.1 through 16 nightly.  

I haven't had any luck reproducing the South Park crash on my machines here, are you still seeing it?

Comment 14

[Bob Clary [:bc] (inactive)]

I have not seen this crash again using the southpark... url after repeated attempts using debug builds. I was able to get a couple of the 'thread-less' minidumps on nightly and aurora for 32bit builds running on Windows 7 64bit. Running under a 32bit nightly/17 debug build on windows 7 32bit and 64bit I have not crashed after repeated starts and stops.

In total, automation has not seen this particular signature which was reproducible on other urls as well since I started testing with 11.3.300.265 around 2012-07-08.

Using Firefox 14.0.1 on Windows 7 32bit and 64bit I was able to get a hang on shutdown after many repeated attempts. I captured MS dumps for firefox, plugin-container and the flash processes if anyone is interested. I'll keep them until I clean up the vms where they are currently stored. Speak now or lose out. The stack for the hung firefox process showed:

>	ntdll.dll!_KiFastSystemCallRet@0() 	
 	ntdll.dll!_ZwWaitForSingleObject@12()  + 0xc bytes	
 	KernelBase.dll!_WaitForSingleObjectEx@12()  + 0x6c bytes	
 	kernel32.dll!_WaitForSingleObjectExImplementation@12()  + 0x43 bytes	
 	kernel32.dll!_WaitForSingleObject@8()  + 0x12 bytes	
 	nspr4.dll!PR_Wait(PRMonitor * mon, unsigned int ticks)  Line 184 + 0xae bytes	C
 	xul.dll!mozilla::ReentrantMonitor::Wait(unsigned int interval)  Line 122 + 0xc bytes	C++
 	xul.dll!nsHttpConnectionMgr::Shutdown()  Line 194 + 0xa bytes	C++
 	xul.dll!nsHttpHandler::Observe(nsISupports * subject, const char * topic, const wchar_t * data)  Line 1641	C++
 	xul.dll!nsObserverList::NotifyObservers(nsISupports * aSubject, const char * aTopic, const wchar_t * someData)  Line 130 + 0x25 bytes	C++
 	xul.dll!nsObserverService::NotifyObservers(nsISupports * aSubject, const char * aTopic, const wchar_t * someData)  Line 182 + 0x12 bytes	C++
 	xul.dll!nsXREDirProvider::DoShutdown()  Line 838	C++
 	xul.dll!ScopedXPCOMStartup::~ScopedXPCOMStartup()  Line 1127	C++
 	xul.dll!XREMain::XRE_main(int argc, char * * argv, const nsXREAppData * aAppData)  Line 3879 + 0xc bytes	C++
 	xul.dll!XRE_main(int argc, char * * argv, const nsXREAppData * aAppData)  Line 3933 + 0xd bytes	C++
 	firefox.exe!wmain(int argc, wchar_t * * argv)  Line 107 + 0x50f bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 552 + 0x17 bytes	C
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes

Comment 15

[Daniel Veditz [:dveditz]]

Is this FIXED or WORKSFORME? if we know what fixed it is it something we want on older branches?

Comment 16

[Benjamin Smedberg]

This is FIXED by Adobe in FlashPlayer.

Comment 17

[Bob Clary [:bc] (inactive)]

Agreed.

Comment 18

[BMO Automation]

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