434163 - Browsing to GameSpy causes Firefox to crash in js3250.dll

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Eric Burnett]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0

The crash occurs on both beta 4 and RC1, and is not an extension problem; disabling all extensions doesn't have any effect.

It seems to happen when the page completes loading, rather than starts, as I can see the rendered page before firefox crashes.

Reproducible: Always

Steps to Reproduce:
1. Go to http://pc.gamespy.com/pc/battlefield-heroes/873765p1.html
Actual Results:  
Crash:
Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	firefox.exe
  Application Version:	1.9.0.3054
  Application Timestamp:	48285372
  Fault Module Name:	js3250.dll
  Fault Module Version:	4.0.0.0
  Fault Module Timestamp:	4828540d
  Exception Code:	c0000005
  Exception Offset:	0004692b
  OS Version:	6.0.6000.2.0.0.256.1
  Locale ID:	1033
  Additional Information 1:	8d13
  Additional Information 2:	cdca9b1d21d12b77d84f02df48e34311
  Additional Information 3:	8d13
  Additional Information 4:	cdca9b1d21d12b77d84f02df48e34311

Comment 1

[Nochum Sossonko [:Natch]]

WFM:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008051706 Minefield/3.0pre

does it happen every time?

Comment 2

[Eric Burnett]

Yep, 100% of the time. I have also tried uninstalling and then reinstalling Firefox (although I did not let it remove the saved user data), and that had no effect.

Comment 3

[Nochum Sossonko [:Natch]]

Heres a thought:

save your profile http://kb.mozillazine.org/Profile_backup, perform a full uninstall (letting it remove the saved user data) and try it on a fresh profile (better yet in safe mode http://kb.mozillazine.org/Safe_mode).

BTW it would probably be good if you'd attach the crash report (if you got one) available through about:crashes.

Comment 4

[Eric Burnett]

Ok, on a fresh install with no profile information whatsoever, with or without safe mode, it still crashes. The only configuration I made before testing it was to setup the proxy, although I don't see how using a proxy could cause this error. I will note that it is a very strict (university) proxy, however.

Firefox does not generate crash reports for me. I assume that is because I have a debugger installed, and the Windows hook gets there first?

Comment 5

[Eric Burnett]

Ok, built Firefox from source. The exception is

Unhandled exception at 0x6c006866 (js3250.dll) in firefox.exe: 0xC0000005: Access violation reading location 0x0000000c.

And the call stack is

  js3250.dll!JS_SetPrivate(JSContext * cx=0x0428b198, JSObject * obj=0x00000000, void * data=0x00000000)  Line 2887 + 0x3 bytes	C
  gkplugin.dll!NPObjWrapperPluginDestroyedCallback(PLDHashTable * table=0x6bab8434, PLDHashEntryHdr * hdr=0x0aed2db0, unsigned int number=0, void * arg=0x0015f54c)  Line 1805 + 0x16 bytes	C++
  xpcom_core.dll!PL_DHashTableEnumerate(PLDHashTable * table=0x6bab8434, PLDHashOperator (PLDHashTable *, PLDHashEntryHdr *, unsigned int, void *)* etor=0x6ba8f7f0, void * arg=0x0015f54c)  Line 724 + 0x19 bytes	C
  gkplugin.dll!nsJSNPRuntime::OnPluginDestroy(_NPP * npp=0x09a5dbfc)  Line 1846 + 0x14 bytes	C++
  gkplugin.dll!ns4xPluginInstance::Stop()  Line 960 + 0xc bytes	C++
  gklayout.dll!DoStopPlugin(nsPluginInstanceOwner * aInstanceOwner=0x0aa9fa70, int aDelayedStop=0)  Line 1828	C++
  gklayout.dll!nsStopPluginRunnable::Run()  Line 1890 + 0x13 bytes	C++
  xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0015f714)  Line 511	C++
  xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x01acff88, int mayWait=1)  Line 227 + 0x16 bytes	C++
  gkwidget.dll!nsBaseAppShell::Run()  Line 170 + 0xc bytes	C++
  tkitcmps.dll!nsAppStartup::Run()  Line 181 + 0x1c bytes	C++
  xul.dll!XRE_main(int argc=1, char * * argv=0x01ae0fa8, const nsXREAppData * aAppData=0x01acc6e8)  Line 3170 + 0x25 bytes	C++
  firefox.exe!NS_internal_main(int argc=1, char * * argv=0x01ae0fa8)  Line 158 + 0x12 bytes	C++
  firefox.exe!wmain(int argc=1, wchar_t * * argv=0x01ae1d88)  Line 87 + 0xd bytes	C++
  firefox.exe!__tmainCRTStartup()  Line 594 + 0x19 bytes	C
  firefox.exe!wmainCRTStartup()  Line 414	C


I'll continue to poke around and see what I can find.

Comment 6

[Nochum Sossonko [:Natch]]

That seems to be a microsoft error report, I've found a few support topics about it, obviously very inconclusive as they're not related directly to firefox, however take a look at these pages:

http://support.microsoft.com/kb/240023 (probably unrelated)

http://support.microsoft.com/kb/903251 & http://support.microsoft.com/kb/811193 (maybe related)

http://support.microsoft.com/kb/158552 (again probably unrelated),

there are others, but you probably get the point (you can search support.microsoft.com for this error code and see all the entries, and maybe see if any apply to you).

It would probably be more useful if a)you can get a mozilla specific error code/stack, you can use this method to see exactly whats going on...


developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg -- this is probably more useful.

Comment 7

[Boris Zbarsky [:bzbarsky]]

I think given comment 5 we can certainly confirm it.  Calling JS_SetPrivate on a null JSObject* seems like a bad idea, for sure.  ;)

Null-checking entry->mJSObj would be pretty simple.  But does it make sense that the mJSObj could have gone null in the meantime?

Comment 8

[Boris Zbarsky [:bzbarsky]]

I guess it does given all the calls into various hooks we make here.  I would think we should grab a local ref to the JSObject in this method before doing all those (and an auto-root or whatever).

Comment 9

[Eric Burnett]

However we fix the call to JS_SetPrivate, we also need check if the entry is still live, and if so return PL_DHASH_NEXT rather than PL_DHASH_REMOVE. 

Comment 10

[Eric Burnett]

Whoops, other way around. If its NOT live return PL_DHASH_NEXT so we don't try to remote it again.

Comment 11

[Johnny Stenback (:jst)]

There's a bigger problem at hand here than that. The hashtable is apparently mutated while we're enumerating the table here, and that's not permitted. We need to guard against that and see if that solves this problem, if not we need to think about something else to do here.

Comment 12

[Eric Burnett]

In that case, this might help. The entry is being removed from the hash table during the call npobj->_class->deallocate(npobj);. The last reference to the NPObject is gone, so it turns around and nulls out the JSObject, then removes it from the hash table itself. 

Partial call stack:

  xpcom_core.dll!PL_DHashClearEntryStub(PLDHashTable * table=0x67e38434, PLDHashEntryHdr * entry=0x068e89a8)  Line 150 + 0x12 bytes	C
  xpcom_core.dll!PL_DHashTableRawRemove(PLDHashTable * table=0x67e38434, PLDHashEntryHdr * entry=0x068e89a8)  Line 693 + 0x12 bytes	C
  gkplugin.dll!nsNPObjWrapper::OnDestroy(NPObject * npobj=0x02b82ce0)  Line 1659 + 0xf bytes	C++
  gkplugin.dll!_releaseobject(NPObject * npobj=0x02b82ce0)  Line 1743 + 0x9 bytes	C++

... missing frames ...

  gkplugin.dll!NPObjWrapperPluginDestroyedCallback(PLDHashTable * table=0x67e38434, PLDHashEntryHdr * hdr=0x068e89a8, unsigned int number=0, void * arg=0x0040f1c4)  Line 1805 + 0xe bytes	C++

Comment 13

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch per comment 11

Eric, does this fix the problem for you?

Comment 14

[Eric Burnett]

Unfortunately, the webpage in question seems to have been updated, so even the builds that crashed before can access it properly now. As I don't know another way to trigger the bug, I'm not sure how I can verify the fix. Any thoughts?

(Sorry about the late reply, was on holidays)

Comment 15

[Boris Zbarsky [:bzbarsky]]

Does the old version of the site one can get through http://www.archive.org show the bug?

Comment 16

[Eric Burnett]

Nope, none of the archived pages trigger the bug, but I will note that the pages for the time period in question won't show up for months yet - the internet archive has a 6 month delay in posting content. I suppose if all else fails, I can (hopefully) test this three months down the line.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Pushed changeset 651fd6b9c460.