spin off from Bug 526587 - new crashes as fall out of frame poisoning 2009 11 22 top list at https://bug526587.bugzilla.mozilla.org/attachment.cgi?id=414317&t=ytKa49fedH shows #10. top crash with 104 crashes as 0xfffffffff0dea7ff Windows NT nsAsyncInstantiateEvent::Run() http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsAsyncInstantiateEvent::Run%28%29 http://crash-stats.mozilla.com/report/index/ff0ee1c5-5ee6-4676-8167-2fa0f2091124 0 @0xf0dea7ff 1 xul.dll nsAsyncInstantiateEvent::Run content/base/src/nsObjectLoadingContent.cpp:156 2 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:527 3 xul.dll nsBaseAppShell::Run widget/src/xpwidgets/nsBaseAppShell.cpp:170 4 xul.dll nsAppStartup::Run toolkit/components/startup/src/nsAppStartup.cpp:182 5 nspr4.dll PR_GetEnv 6 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp:120 7 firefox.exe __tmainCRTStartup obj-firefox/memory/jemalloc/crtsrc/crtexe.c:591 8 kernel32.dll BaseThreadInitThunk 9 ntdll.dll __RtlUserThreadStart 10 ntdll.dll _RtlUserThreadStart If there is a fix resulting from quick code review, or quick STR it would be good to take in 1.9.1

the signature nsAsyncInstantiateEvent::Run() seem to stretch across releases and is found on both windows and mac in the 2009 11 22 top fp list at https://bug526587.bugzilla.mozilla.org/attachment.cgi?id=414317&t=ytKa49fedH at rank #'s 215. 1 0xfffffffff0dea7ff Mac OS X nsAsyncInstantiateEvent::Run() 238. 1 0xf0dea7ff Windows NT nsAsyncInstantiateEvent::Run() 241. 1 0xf0dea7ff Mac OS X nsAsyncInstantiateEvent::Run()

not much to start the investigation with. no user comments and low chance of the urls producing much. several are behind some kind of google or facebook or http://iwiw.hu/ auth. there were a couple that seem to indicate users might be in some stage of updating/installing plugins http://www.flashbangstudios.com/amoeball/amoeball_nomusic.htm http://www.adobe.com/products/reader/dlm/firefox_steps.html source around the second frame of the stack was changed last summer during 3.6 development. http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/3b49c063bb42/xpcom/threads/nsThread.cpp#l527

Interesting. It looks like mContent is poisoned, at least for the stacks I looked at. But the object which has the mContent member (nsAsyncInstantiateEvent) is just allocated with ::operator new, not out of the presshell arena. Zack, any idea what might be going out here?

The only thing I can think of is maybe it's the 'frame' variable that's poisoned and inlining has distorted the code unrecognizably. We should have crashed before that point in that case, but I can almost see the compiler mangling the code to where the crash appears to be on line 151.

Er, I meant line 156.

So we'd be crashing on the do_QueryFrame call in that case? I can't see anything else in that method that would even notice if |frame| is either poisoned or points to a poison address....

Yeah, it's the do_QueryFrame call that I would think would have crashed. Maybe MSVC++ can optimize it out from the static types, though. The other weird thing is that these stacks look like they *jumped to* the poison address, but that shouldn't be possible from a virtual method call on a nsIContent object. I haven't enough brain right now to stare at assembly dumps.

Speculatively blocking until we can see the effects of 3.6b4 on the crash data here. Keep us posted, Choff.

This *might* be correlated with third-party modules: 31% (9/29) vs. 0% (40/12858) np_gp.dll ... 14% (4/29) vs. 0% (15/12858) snap_libW.dll 14% (4/29) vs. 0% (20/12858) achook.dll though that could just be one user crashing 9 times and another crashing 4 times. I also don't think this should be a blocker: * it's way too far down on the list to block for the crashiness (less than 0.2% of 3.6b4 crashes) * if there are security implications, they're most likely on 1.9.1 and *not* 1.9.2

I agree with dbaron that this shouldn't be a blocker.

-'ing based on comment 9 and 10.

snap_libW.dll looks like it belongs to http://ivanheckman.com/allsnap/ -- interesting message there.. "There is no reason why this system tray app should crash your computer! ;-) achook.dll appears to be part of some autodesk app. http://dllrepairs.com/library/achook.dll/ http://groups.google.com/group/mozilla.general/browse_thread/thread/079f6858c9c51ba3?pli=1 suggests np_gp.dll gets installed silently into firefox when flash 10 for IE is installed. tomcat, next flash automation run for flash we could also running the flash 10 installer for both IE and Firefox as pre-set-up steps to see if np_gp.dll turns up problems here, or elsewhere.

Crash bugs where all we have are stats should not be security-sensitive. If you figure out steps to reproduce, *that* should be security-sensitive.

bp-29823498-e6fa-4cb2-a551-b81fe2100322 has a reporter's email address someone could contact. (no other crashes from the past month have addresses)

This crash doesn't occur at same rate as originally reported for current versions. And I doubt crashes for current versions are related to original bug report. Please reopen if you disagree https://crash-stats-php.mozilla.org/report/list?product=Firefox&query_search=signature&query_type=exact&query=nsAsyncInstantiateEvent%3A%3ARun%28%29&reason_type=contains&date=07%2F29%2F2013%2016%3A13%3A29&range_value=8&range_unit=weeks&hang_type=any&process_type=any&do_query=1&admin=1&signature=nsAsyncInstantiateEvent%3A%3ARun%28%29 bp-6182428f-32df-4123-88c6-0fa0c2130725 fx22