Re: nsIBadCertListener and JVM death

On Tuesday 12 June 2007, Greg Bowyer wrote:
Hello,

> A bug that came to my attention today is that when the thing hits a
> broken secure certificate, it presents the (not present) end user with a
> confirmation dialog asking them what to do.
> Since the thing is headless, I need to automatically handle this myself,
> the code that I have implemented for this is nsIBadCertListener which I
> then register with the componentRegistrar like so
Isn't it possible to implement that using nsIPromptService?  
This is what we do to solve the same problem as you have.

> However when this code runs I get the lovely world of VM death, and
> hence a h_pid_err_xxx.log.
> Running this on my 1.9 build (which has debug info on) I get the
> following information from XPCom / XULRunner which leads me to believe
> that this is a fault in JavaXPCom's handling of threads. I assume that
> whatever invokes the security prompt (Necko / libnspr prehaps ?!?!?) is
> spawning a thread for it, which appears to confuse things.

Most of the code in Mozilla is not thread-safe. 

I mean, not multi-threaded in the sense as you know from java.
Mozilla mostly uses the concept of event queues to break
execution into smaller blocks.
E.g. all page rendering code, gui, mouse and key handling, 
JS execution run on the same (GUI) thread.

Therefore, there are several mechanisms in mozilla code
that check that xpcom components are accessed in
a tread-safe way.

> ###!!! ASSERTION: nsJavaXPTCStub not thread-safe:
> '_mOwningThread.GetThread() == PR_GetCurrentThread()', file
For example, this check is implemented in AddRef and tests that 
the method (current code) is executing on the same thread 
that created instance of the xpcom component.
So, my estimate is that you have created an instance of XPCOM 
object on a java thread A and then you try to access it on thread B.

> ###!!! ASSERTION: Current thread not attached to given JVM instance: 'rc
> == JNI_OK && env != nsnull', file
> /home/greg/projects/xulrunner/mozilla/extensions/java/xpcom/src/nsJavaXPCOM
>BindingUtils.cpp, line 975
This error occurs when a native thread tries to do a callback to java,
but because it is not attached to the jvm, it can not obtain
the jvm pointer.
This simplest solution without changes in javaxpcom is 
1) implement your code in a way, that the callback occurs on GUI thread
2) reimplement this particular part of code as a native xpcom/c++ component

best regards,
Michal