Comment 12 for bug 927282

This abort is caused by using a JSRuntime (via _getstringidentifier) from off the main thread and was added by bug 650411. Incidentally, it looks like this was already an error (see the NS_IsMainThread check in http://mxr.mozilla.org/mozilla-central/source/dom/plugins/base/nsNPAPIPlugin.cpp#1407), it just wasn't causing failures. With JSRuntime being made single-threaded (announced a few months ago: http://groups.google.com/group/mozilla.dev.tech.js-engine/msg/ae5f22f39e4fd150), this will definitely cause unsafe race-conditions.

The callstack for the crash is:

#3 JS_AbortIfWrongThread
#4 js_NewContext
#5 JS_NewContext
#6 XPCJSContextStack::GetSafeJSContext
#7 nsXPConnect::GetSafeJSContext
#8 mozilla::plugins::parent::_getstringidentifier
#9 PluginRequestProcessor::sendMember
   from /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/IcedTeaPlugin.so
#10 queue_processor
   from /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/IcedTeaPlugin.so
#11 start_thread

Looking at PluginRequestProcessor::sendMember in icedtea-web-1.1.4/plugin/icedteanp/IcedTeaPluginRequestProcessor.cc, I see the comment:

 * This is a static function, called in another thread. Since certain data
 * can only be requested from the main thread in Mozilla, this function
 * does whatever it can seperately, and then makes an internal request that
 * causes _sendMember to do the rest of the work.

so perhaps the fix is to just move the get*identifier calls to the part that gets executed on the main thread.

Does anyone know who to contact about getting this fixed on the IcedTea side? Thus far, IcedTea seems to be the only plugin/addon hitting this and only for some applets (I tested quite a few before landing), so I do not want to back out the whole single-threaded check for this one case.