1. http://www.transparency.eex.com/de/ (may need to reload) 2. Crash Windows, Linux - Aurora, Nightly but not Beta. Breakpad's exploitable tool rates this as medium on Windows Operating system: Windows NT 5.1.2600 Service Pack 3 CPU: x86 GenuineIntel family 6 model 37 stepping 1 1 CPU Crash reason: EXCEPTION_ACCESS_VIOLATION_EXEC Crash address: 0x939ee30 Thread 0 (crashed) 0 0x939ee30 eip = 0x0939ee30 esp = 0x0012d054 ebp = 0x0012d060 ebx = 0x00000001 esi = 0x00934618 edi = 0x00228fd8 eax = 0x0939ee30 ecx = 0x0939ee30 edx = 0x091bf9a0 efl = 0x00010206 Found by: given as instruction pointer in context 1 xul.dll!nsRefPtr<nsPluginStreamListenerPeer>::operator=(nsPluginStreamListenerPeer *) [nsAutoPtr.h : 930 + 0xb] eip = 0x033640a3 esp = 0x0012d068 ebp = 0x0012d070 Found by: previous frame's frame pointer 2 xul.dll!nsNPAPIPluginStreamListener::SetStreamListenerPeer(nsPluginStreamListenerPeer *) [nsNPAPIPluginStreamListener.h : 99 + 0x15] eip = 0x03365526 esp = 0x0012d078 ebp = 0x0012d080 Found by: call frame info 3 xul.dll!nsPluginStreamListenerPeer::SetUpStreamListener(nsIRequest *,nsIURI *) [nsPluginStreamListenerPeer.cpp : 1104 + 0x1b] eip = 0x03367cef esp = 0x0012d088 ebp = 0x0012d2f8 Found by: call frame info 4 xul.dll!nsPluginStreamListenerPeer::OnStartRequest(nsIRequest *,nsISupports *) [nsPluginStreamListenerPeer.cpp : 616 + 0x14] eip = 0x03366624 esp = 0x0012d300 ebp = 0x0012d40c Found by: call frame info 5 xul.dll!nsObjectLoadingContent::LoadObject(bool,bool,nsIRequest *) [nsObjectLoadingContent.cpp : 1739 + 0x38] eip = 0x02759ab6 esp = 0x0012d414 ebp = 0x0012d4fc Found by: call frame info

Any chance of a local testcase? Is it possible to get a nightly regression range?

local test case? not likely from my experience. regression range? sure. the need to reload sometimes makes it tricky but I'll give it a try.

Found regression between 20120809002245-20120810012545 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3199bc043da4&tochange=b5ae446888f5 http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/08/2012-08-09-mozilla-central-debug/firefox-17.0a1.en-US.debug-linux-i686.tar.bz2 http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/08/2012-08-11-mozilla-central-debug/firefox-17.0a1.en-US.debug-linux-i686.tar.bz2

bp-3420bab4-53ab-4dc7-9d96-36a612120911 Firefox 18.0a1 Crash Report [@ nsPluginStreamListenerPeer::SetUpStreamListener ] no luck on local test so far.

Likely candidates: John Schoenick — Bug 764480 - Don't try to instantiate plugins while not bound to tree. r=josh John Schoenick — Bug 334288 - Use early returns in nsObjectLoadingContent::IsSupportedDocument. r=bz

This is the same as bug 788107 (which is non-secure) and I *think* is the same re-entrance issue in bug 787778.

bug 788107 was blamed on bug 745030 which should have given a regression range a couple days earlier than comment 3

The crashing on this bug will be fixed by bug 787778, but it then begins printing assertions ("Should not be tearing down a plugin at this point!") This properly aborts the outer load when re-entering plugin instances, but DoStopPlugin doesn't account for stopping multiple instances at once (though it should), so it doesn't fully stop re-entrance. Bug 767635 will fix up the plugin stopping, which should fix re-entrance completely. This assertion may still be a security bug, however, as DoStopPlugin can keep references to nsObjectLoadingContent, but is called from said's destructor. Ugh.

Is this the same as bug 790537?

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #9) > Is this the same as bug 790537? If there crashes there stopped with the landing of bug 787778 then it almost certainly is, otherwise I would have to investigate further.

(In reply to John Schoenick [:johns] from comment #10) > (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #9) > > Is this the same as bug 790537? > > If there crashes there stopped with the landing of bug 787778 then it almost > certainly is, otherwise I would have to investigate further. Hmm, bp-4c549eab-7de6-4d2d-b295-b77cc2121017 seems to be in the Aurora build 20121017042010, which is probably after the bug 787778 landing.

Note I had retested this url on 10/9 and reproduced on all three branches. I just retested and did not reproduce. But I can reproduce the assertion "Should not be tearing down a plugin at this point!" on all three branches on windows and linux.

(In reply to Bob Clary [:bc:] from comment #12) > Note I had retested this url on 10/9 and reproduced on all three branches. I > just retested and did not reproduce. But I can reproduce the assertion > "Should not be tearing down a plugin at this point!" on all three branches > on windows and linux. Can we call this fixed now John?

The crash this bug was created for is fixed by 787778, so I think this can be closed. The test case still triggers a non-crash assertion, which will be fixed by bug 767635.