73.29 KB, text/plain
90.39 KB, text/plain
29.65 KB, text/plain
74.35 KB, application/x-shockwave-flash
Created attachment 684036 [details] nsPluginStreamListenerPeer::OnDataAvailable crash report 1. http://www.orchlon.mn/web/guest ( I removed the sessionid in case it is needed I have it) 2. Crash Windows and sometimes Linux In crash automation I hit several crashes. One was flagged by breakpad's tool as exploitable: nsPluginStreamListenerPeer::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned __int64, unsigned int) mozilla::net::nsHttpChannel::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned __int64, unsigned int) nsInputStreamPump::OnStateTransfer() nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) nsInputStreamReadyEvent::Run() EXCEPTION_ACCESS_VIOLATION_EXEC 0xffffffffdddddddd Operating system: Windows NT 6.1.7601 Service Pack 1 CPU: x86 GenuineIntel family 6 model 37 stepping 1 2 CPUs Crash reason: EXCEPTION_ACCESS_VIOLATION_EXEC Crash address: 0xffffffffdddddddd Thread 0 (crashed) 0 0xdddddddd eip = 0xdddddddd esp = 0x0031d3bc ebp = 0x0031d4c0 ebx = 0x00000000 esi = 0x0033c2c0 edi = 0x00000000 eax = 0xdddddddd ecx = 0x068e8464 edx = 0x068e8104 efl = 0x00010202 Found by: given as instruction pointer in context An EXEC violation at a deleted address is a Bad Thing(tm). Linux crashed at mozalloc_abort | Abort | NS_DebugBreak_P | mozilla::plugins::PluginModuleParent::StreamCast mozilla::plugins::PluginModuleParent::NPP_WriteReady nsNPAPIPluginStreamListener::OnDataAvailable nsPluginStreamListenerPeer::OnDataAvailable mozilla::net::nsHttpChannel::OnDataAvailable with ABORT: Corrupted plugin stream data. Windows also hit a plugin crash at: F21225463__________________________________________________________________________________________________________ F1717497556________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ F1470906166_________________________________________________ F_1513036030________________________________________ F_424569316__________________________________________________ Running the site on Windows 7 64bit with Windgb and !exploitable hit: (ad4.b5c): Access violation - code c0000005 (!!! second chance !!!) eax=6bfab536 ebx=fffde000 ecx=001d07e0 edx=0062b3c4 esi=00000005 edi=0062b194 eip=6bfab536 esp=004cfd54 ebp=004cfd6c iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202 <Unloaded_NPSWF32_11_5_502_110.dll>+0x6bb536: 6bfab536 ?? ??? 1:023> !load winext/msec.dll 1:023> !exploitable *** ERROR: Module load completed but symbols could not be loaded for plugin-container.exe Exploitability Classification: EXPLOITABLE Recommended Bug Title: Exploitable - Data Execution Prevention Violation starting at <Unloaded_NPSWF32_11_5_502_110.dll>+0x00000000006bb536 (Hash=0x1b0a6843.0x09245e48) User mode DEP access violations are exploitable.
Loading this in Nightly debug under windbg shows the exploitable crash on shutdown.
Severity: normal → critical
Keywords: reproducible, testcase
Assignee: nobody → benjamin
Status: NEW → ASSIGNED
Benjamin: I think the original exploitable crash may be related to bug 813619 and bug 747066. I can't reproduce it anymore. When it doesn't crash the site uses > 1G of memory and hits ABORT: State invariants violated: 'mState == FAILED || mState == STARTED || mState == CLONED', file c:/work/mozilla/builds/nightly/mozilla/widget/windows/AudioSession.cpp, line 346 The memory usage has been causing me tribbles trying to bisect. I'll try to nail it down better. bz: Thing the original report was related to bug 747066 ?
Seems unlikely at first glance, but who knows...
Bill any thoughts on Comment 5?
status-firefox19: --- → affected
status-firefox20: --- → affected
tracking-firefox19: --- → ?
tracking-firefox20: --- → +
I think dveditz meant to + for 19 here, so doing that now.
tracking-firefox19: ? → +
Given what we now know about bug 747066, it seems entirely possible that this was caused by it.
(In reply to Bill McCloskey (:billm) from comment #9) > Given what we now know about bug 747066, it seems entirely possible that > this was caused by it. Given this is a sec-crit, does that mean we should uplift the patch from that bug?
Bug 747066 doesn't fix anything. I landed a broken version of the patch, and it caused crashes that looked like this. Then I backed it out, fixed it, and relanded. The bad code landed on 19 and was backed out of 19, so I don't think we need to worry.
Thanks Bill for clarity can you confirm if the tracking flags are correct for this bug?
It sounds like this is "fixed" in 19 and 20, by a backout of the original patch that caused the regression.
status-firefox19: affected → fixed
status-firefox20: affected → fixed
Though it would be good if that was verified on 19 and 20.
I've attempted to reproduce using local builds on Windows and was unable to do so. I also have submitted the original url to automation and it has completed testing with Windows XP and Windows 7 and did not reproduce either version of the crash. I'd like to call this fixed by Bug 747066 and open it up. Bill, does that sound right?
That sounds good to me.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 747066
You need to log in before you can comment on or make changes to this bug.