JavaScript nsBadCertListener component results in too much recursion errors

NEW
Unassigned

Status

()

12 years ago
11 years ago

People

(Reporter: andrew, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0


A Javascript component that registers itself with the "@mozilla.org/nsBadCertListener;1" contractID will result in "too much recursion" errors when the component is loaded in subsequent sessions. 

This component is implemented in a Firefox (and TB) extension and when first registered, (ie, after the extension is installed or after deleting compreg.dat), the component will work as expected. If I then close and restart the browser anytime Firefox tries to load the component it will simply fail and throw two "too much recursion" errors in the error console. 

I believe this is a regression - it only seems to occur on Linux machines in Firefox 2 (and Thunderbird 2a). It does work in previous versions on all platforms. FWIW, I think I've traced it back to first appearing in beta 2 of Firefox 2.



Reproducible: Always

Steps to Reproduce:
You can reproduce this using the Remember Mismatched Domains extension.

1. using FF2 (Linux) install the RMD extension:
https://addons.mozilla.org/firefox/2131/
2. After installing the extension and restarting the browser for the first time browse to a website that triggers a mismatched domains warning (I like to test against, https://www.google.ca/ ). You will be presented with the expected mismatched domains warning.
3. Cancel (or accept) the warning and restart the browser
4. Again, browse to a website that triggers the mismatch warning.


Actual Results:  
On the second visit the website will be prevented from loading and the error console will show two "too much recursion" errors.

Expected Results:  
The page loads and presents the mismatch warning.

A reasonable first thought is that the Javascript component is the cause of the errors so I've stripped it down to the essentials:


const CLASS_ID = Components.ID("{733005a0-6c1d-11db-bd13-0800200c9a66}");
const CLASS_NAME = "RMD implementation of BadCertListener";
const CONTRACT_ID = "@mozilla.org/nsBadCertListener;1";


/* rmdBadCertListener */

function rmdBadCertListener() {
    dump("RMD :: constructor \n");
};

rmdBadCertListener.prototype = {
    confirmCertExpired: function(socketInfo, cert) {
        dump("RMD :: do confirmCertExpired \n");
        return false;
    },

    confirmMismatchDomain: function(socketInfo, targetURL, cert) {
        dump("RMD :: do confirmMismatchDomain \n");
   	return false;
    },

    confirmUnknownIssuer: function(socketInfo, cert, certAddType) {
   	dump("RMDfalsedo confirmUnknownIssuer \n");
   	return false;
    },

    notifyCrlNextupdate: function(socketInfo, targetURL, cert) {
   	dump("RMD :: do notifyCrlNextupdate \n");
    },

   // nsISupports
    QueryInterface: function(aIID)  {
        if (!aIID.equals(Components.interfaces.nsIBadCertListener) &&
            !aIID.equals(Components.interfaces.nsISupports))
                throw Components.results.NS_ERROR_NO_INTERFACE;
            return this;
    }
};

/* */
var rmdBadCertListenerFactory = {
  createInstance: function (aOuter, aIID)  {
    if (aOuter != null)
      throw Components.results.NS_ERROR_NO_AGGREGATION;
    return (new rmdBadCertListener()).QueryInterface(aIID);
  },
};

var rmdBadCertListenerModule = {
  _firstTime: true,
  registerSelf: function(aCompMgr, aFileSpec, aLocation, aType)  {
    if (this._firstTime) {
      this._firstTime = false;
      throw Components.results.NS_ERROR_FACTORY_REGISTER_AGAIN;
    }
    aCompMgr = aCompMgr.QueryInterface(Components.interfaces.nsIComponentRegistrar);
    aCompMgr.registerFactoryLocation(CLASS_ID, CLASS_NAME, CONTRACT_ID, aFileSpec, aLocation, aType);
  },

  unregisterSelf: function(aCompMgr, aLocation, aType) {
    aCompMgr = aCompMgr.QueryInterface(Components.interfaces.nsIComponentRegistrar);
    aCompMgr.unregisterFactoryLocation(CLASS_ID, aLocation);
  },

  getClassObject: function(aCompMgr, aCID, aIID)  {
    if (!aIID.equals(Components.interfaces.nsIFactory))
      throw Components.results.NS_ERROR_NOT_IMPLEMENTED;
    if (aCID.equals(CLASS_ID))
      return rmdBadCertListenerFactory;
    throw Components.results.NS_ERROR_NO_INTERFACE;
  },

  canUnload: function(aCompMgr) { return true; }
};

function NSGetModule(aCompMgr, aFileSpec) { return rmdBadCertListenerModule; }
Summary: Javascript nsBadCertListener component results in too much recursion errors → JavaScript nsBadCertListener component results in too much recursion errors

Comment 1

12 years ago
I appear to also have been caught by this bug, doing work with xulrunner

a long and rambeling thread is here 
http://groups.google.com/group/mozilla.dev.tech.java/browse_thread/thread/8f17384135a20a37/a39dadb14c8c8d5f?#a39dadb14c8c8d5f

The gist is, if I implement the nsBadCertListener in Java (via JavaXPCom) I get the following fails 
###!!! ASSERTION: nsSecureBrowserUIImpl not thread-safe:
'_mOwningThread.GetThread() == PR_GetCurrentThread()', file
/home/greg/projects/xulrunner/mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.cpp,
line 165
###!!! ASSERTION: nsSecureBrowserUIImpl not thread-safe:
'_mOwningThread.GetThread() == PR_GetCurrentThread()', file
/home/greg/projects/xulrunner/mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.cpp,
line 165
###!!! ASSERTION: nsSecureBrowserUIImpl not thread-safe:
'_mOwningThread.GetThread() == PR_GetCurrentThread()', file
/home/greg/projects/xulrunner/mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.cpp,
line 165
###!!! ASSERTION: nsSecureBrowserUIImpl not thread-safe:
'_mOwningThread.GetThread() == PR_GetCurrentThread()', file
/home/greg/projects/xulrunner/mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.cpp,
line 165
###!!! ASSERTION: nsJavaXPTCStub not thread-safe:
'_mOwningThread.GetThread() == PR_GetCurrentThread()', file
/home/greg/projects/xulrunner/mozilla/extensions/java/xpcom/src/nsJavaXPTCStub.cpp,
line 99
###!!! ASSERTION: Current thread not attached to given JVM instance: 'rc
== JNI_OK && env != nsnull', file
/home/greg/projects/xulrunner/mozilla/extensions/java/xpcom/src/nsJavaXPCOMBindingUtils.cpp,
line 975 

If I implement it in javascript I get a success on first run (when I have no compreg or xpti.dat) 
but all other runs fail with the following

###!!! ASSERTION: nsSecureBrowserUIImpl not thread-safe:
'_mOwningThread.GetThread() == PR_GetCurrentThread()', file
/home/greg/projects/xulrunner/mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.cpp,
line 165
Assertion failure: cx->thread->id == js_CurrentThreadId(), at
/home/greg/projects/xulrunner/mozilla/js/src/jsapi.c:829 

Like the bug reporterr I too am running on Linux, I will try the code out on windows to see if I cannot reproduce the issue there

Comment 2

11 years ago
I saw a similar problem with my own JS implementation of a nsIBadCertListener component on Mac OS 10.4 with Firefox 2.0.0.14.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
(Reporter)

Comment 3

11 years ago
This bug looks like it may be around for awhile so for anyone hit by it in the future... a work around seems to be to implement a native (platform specific) component.

Comment 4

11 years ago
I too was able to work around this by implementing a native version of the listener, I am not sure why NSS is complaining about the thread switch.

Updated

11 years ago
Component: XPCOM Registry → XPCOM
You need to log in before you can comment on or make changes to this bug.