530877 - Crashes in [@ nsAsyncInstantiateEvent::Run() ]

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[chris hofmann]

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

Comment 1

[chris hofmann]

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()

Comment 2

[chris hofmann]

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

Comment 3

[Boris Zbarsky [:bzbarsky]]

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?

Comment 4

[Zack Weinberg (:zwol)]

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.

Comment 5

[Zack Weinberg (:zwol)]

Er, I meant line 156.

Comment 6

[Boris Zbarsky [:bzbarsky]]

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....

Comment 7

[Zack Weinberg (:zwol)]

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.

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

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

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[Damon Sicore (:damons)]

-'ing based on comment 9 and 10.

Comment 12

[chris hofmann]

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.

Comment 13

[Jesse Ruderman]

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.

Comment 14

[Wayne Mery (:wsmwk)]

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

Comment 15

[Wayne Mery (:wsmwk)]

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