342423 - JS XPCOM components that implement nsIClassInfo.THREADSAFE still trigger XPConnect WrappedNative thread use warning

Status: RESOLVED DUPLICATE of bug 280236

(Core :: XPConnect, defect)

Description

[Ben Turner (not reading bugmail, use the needinfo flag!)]

One of our XPCOM components is written in JS and is being used in a non-UI thread at shutdown (after observing "profile-before-change"). It was generating a lot of these warnings:

---------------------------------------------------------------
!!!!! XPConnect wrapper thread use error...
  XPConnect WrappedNative is being accessed on multiple threads but the
  underlying native xpcom object does not have a nsIClassInfo with the
  'THREADSAFE' flag set
  wrapper: [object nsXPCComponents @ 0x231f248 (native @ 0x231f1d0)]
  JS call stack...
  0 [native frame]
  1 anonymous(iid = {0be3a41a-6673-494a-a53e-9740a98acff7})
    ["file:///D:/Home/songbird_trunk/dist/components/sbIPlaylistManager.js":843]
      this = [object Object]
  2 anonymous(outer = null, iid = {0be3a41a-6673-494a-a53e-9740a98acff7})
    ["file:///D:/Home/songbird_trunk/dist/components/sbIPlaylistManager.js":907]
      this = [object Object]
      this.createInstance = [function]
  3 [native frame]
---------------------------------------------------------------

Line 843 is the component's QI function, and line 907 is the nsIFactory.createInstance function.

The component is actually threadsafe so I added nsIClassInfo.THREADSAFE to the component like so:

  getInterfaces: function (count) {
    var ifaces = [
      Components.interfaces.nsISupports,
      Components.interfaces.nsIClassInfo,
      SONGBIRD_PLAYLISTMANAGER_IID
    ];
    count.value = ifaces.length;
    return ifaces;
  },
  getHelperForLanguage: function (language) {
    return null;
  },
  contractID: SONGBIRD_PLAYLISTMANAGER_CONTRACTID,
  classDescription: SONGBIRD_PLAYLISTMANAGER_CLASSNAME,
  classID: SONGBIRD_PLAYLISTMANAGER_CID,
  implementationLanguage:
    Components.interfaces.nsIProgrammingLanguage.JAVASCRIPT,
  flags: Components.interfaces.nsIClassInfo.THREADSAFE,

I also adjusted the QI function:

  QueryInterface: function(iid) {
    if (!iid.equals(Components.interfaces.nsISupports) &&
        !iid.equals(Components.interfaces.nsIClassInfo) &&
        !iid.equals(SONGBIRD_PLAYLISTMANAGER_IID))
      throw Components.results.NS_ERROR_NO_INTERFACE;
    return this;
  }

However I still get the exact same thread warnings every time this component is accessed outside of the main thread. I dug around a little and found this:

http://lxr.mozilla.org/mozilla1.8/source/js/src/xpconnect/src/xpcwrappednative.cpp#3084

    XPCWrappedNativeProto* proto = wrapper->GetProto();
    if(proto && proto->ClassIsThreadSafe())
        return;
    PRThread* currentThread = PR_GetCurrentThread();
    if(proto && proto->ClassIsMainThreadOnly())
    {
      // I never get here
      ...
    }
    else if(currentThread != wrapper->mThread)
    {
      // Dump the big warning message I've been seeing
      ...
    }

Here proto is always null (because IsTaggedScope is retrning true) and so the ClassIsThreadSafe() call is never being made. Moreover I added a dump to the QI function and found that no one ever tries to QI to nsIClassInfo before spitting out this warning.

So what's the deal? Is the bug that proto is always null? That seems odd to me. Or did I not add the nsIClassInfo correctly? I'm almost positive that this whole series of events is happening on one thread only (as I've even gone so far as to freeze all the other threads while stepping this execution), so I don't think this is a legitimate warning.

Any ideas?

Comment 1

[timeless]

*** This bug has been marked as a duplicate of 280236 ***