1446683 - Crash in nsTHashtable<T>::s_HashKey | PLDHashTable::Search | mozJSComponentLoader::Unload

Status: RESOLVED WONTFIX

(Core :: XPConnect, defect, P2)

Description

[Julian Seward [:jseward]]

This bug was filed from the Socorro interface and is
report bp-e9d675d5-e948-4852-8b08-fcb710180316.
=============================================================

Top 10 frames of crashing thread:

0 XUL nsTHashtable<nsBaseHashtableET<nsCStringHashKey, nsAutoPtr<mozJSComponentLoader::ModuleEntry> > >::s_HashKey mfbt/HashFunctions.h:123
1 XUL PLDHashTable::Search xpcom/ds/PLDHashTable.cpp:519
2 XUL mozJSComponentLoader::Unload xpcom/ds/nsTHashtable.h:135
3 XUL nsXPCComponents_Utils::Unload js/xpconnect/src/XPCComponents.cpp:2282
4 XUL NS_InvokeByIndex 
5 XUL XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:1951
6 XUL XPC_WN_CallMethod js/xpconnect/src/XPCWrappedNativeJSOps.cpp:913
7 XUL js::InternalCallOrConstruct js/src/vm/JSContext-inl.h:290
8 XUL Interpret js/src/vm/Interpreter.cpp:522
9 XUL js::RunScript js/src/vm/Interpreter.cpp:417

=============================================================

This is the #4 topcrash in the OSX nightly 20180315100042.

Comment 1

[Julian Seward [:jseward]]

Nathan, can you guess from the stack traces who this should be
routed to?  I looked, but I can't guess.

Comment 2

[Nathan Froyd [:froydnj]]

I'd guess this is somewhere in xpconnect, judging from:

1 XUL PLDHashTable::Search xpcom/ds/PLDHashTable.cpp:519
2 XUL mozJSComponentLoader::Unload xpcom/ds/nsTHashtable.h:135
3 XUL nsXPCComponents_Utils::Unload js/xpconnect/src/XPCComponents.cpp:2282

Comment 3

[Andrew McCreight [:mccr8]]

Yes, this is the XPConnect component loader. Kris, any guesses why this could have regressed recently? It looks like it first showed up in the 20180314102135 build, then there were a lot of crashes in the 20180314222911 build.

Comment 4

[Kris Maglione [:kmag]]

(In reply to Andrew McCreight [:mccr8] from comment #3)
> Yes, this is the XPConnect component loader. Kris, any guesses why this
> could have regressed recently? It looks like it first showed up in the
> 20180314102135 build, then there were a lot of crashes in the 20180314222911
> build.

I can't think of anything in the loader that would have caused it. The hash key in this case is a const nsACString& that gets passed through unchanged from XPCComponents::Unload to the ComponentLoaderInfo object. It should always be a valid string. The only way we should ever be able to end up with a null pointer here is if something goes wrong at the XPC/XPIDL layer.

Calling Cu.unload() with null or an empty string doesn't appear to trigger this for me, so I guess it's not something that simple.

All of the crashes do seem to be on OS-X, though, which is odd.

Comment 5

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.

Comment 6

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.