harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [drlvm] Should the launcher print uncaught exceptions?
Date Thu, 21 Sep 2006 15:26:22 GMT
Still, it seems strange that you should have to call DetachCurrentThread
 explicitly to get this behavior.  I would have expected that
DestroyJavaVM alone would cause the uncaught exception handler to fire.
 Not all apps that embed the VM will know to make this work-around.

Regards,
Tim

Oliver Deakin wrote:
> Evgueni Brevnov wrote:
>> Oliver,
>>
>> Yes, I got the same result on RI when starting VM by your simple
>> launcher. Assume it is OK not to print an error message and stacke
>> trace of an unhandled exception in JavaDestroyVM(). How about calling
>> uncaught exception handler? According to the spec it must be called if
>> terminating thread has an exception. The test shows that the handler
>> is not called when VM is created by our launcher.  But if VM is
>> created by RI's launcher then everything works fine and the handler is
>> executed. This means that RI's launcher somehow deals with it (not VM
>> itself). It seems for me as a bug in RI. Do you think so?
> 
> Hi Evgueni,
> 
> I see the same thing - if I run your second Test class (the
> UncaughtExceptionHandler
> test) with my simple launcher on the RI and J9 I do not see any output.
> i.e. the MyHandler.uncaughtException() method is never called.
> 
> Having a Google around I found a link to a Sun bug registered for this [1].
> All our launcher needs to do is call DetachCurrentThread() on the main
> thread before DestroyJavaVM(), and the UncaughtExceptionHandler will
> be called as expected. (This bug only occurs with exception handlers
> registered to the main thread - I verified this with [2] which has its
> non-main
> thread's exception handler called correctly)
> 
> So if you add the line:
>   (*jvm)->DetachCurrentThread(jvm);
> to my simple launcher just before the DestroyJavaVM() call, you will see
> that the MyHandler.uncaughtException() is called for the main thread, and
> the test works as expected.
> 
> This looks like it needs to be added to our launcher - do you agree?
> 
> What is even more interesting is that if I run your more simple Test class
> (the one that just does 'throw new Error("my");'), with the
> DetachCurrentThread()
> call added to the simple launcher I get a stack trace printed on both RI
> and J9!
> Again it appears that this is only a problem with the main thread (if
> you alter
> [2] before so that the handler is not registered, you get the expected
> stack trace).
> So it seems that adding DetachCurrentThread to the launcher fixes both
> problems!
> 
> Regards,
> Oliver
> 
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4992454
> [2]
> public class Test {
>    static class MyHandler implements Thread.UncaughtExceptionHandler {
>        public void uncaughtException(Thread t, Throwable e) {
>            System.out.println("My Handler Called!!!");
>        }
>   }
> 
>    static class MyRunnable implements Runnable {
>        public void run() {
>            Thread.currentThread().setUncaughtExceptionHandler(new
> MyHandler());
>            throw new Error("my");
>        }
>    }
> 
>    public static void main(String [] args) {
>        Thread t = new Thread(new MyRunnable());
>        t.start();
>        try {
>            t.join();
>        } catch (InterruptedException e) {
>            System.out.println("Interrupted!");
>        }
>    }
> }
> 
>>
>> Evgueni
>>
>> On 9/21/06, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
>>> Hi Evgueni,
>>>
>>> I wrote a simple launcher [1] that does the following:
>>> 1) Calls CreateJavaVM
>>> 2) Runs the main method of your Test class below
>>> 3) Calls DestroyJavaVM
>>>
>>> Note that it does *not* call env->ExceptionDescribe() before destroying
>>> the VM.
>>> I tested this launcher against the RI and J9 and found that no stack
>>> trace or
>>> error details are printed.
>>> So I would say that it is standard behaviour for the VM not to output
>>> any
>>> information about uncaught exceptions when shutting down, and that the
>>> launcher
>>> is expected to call ExceptionDescribe() if it wants any details to be
>>> printed.
>>>
>>> So from what you have said below, IMHO we need to:
>>>  - Change DRLVM to not print stack trace if there is an uncaught
>>> exception at
>>> shutdown.
>>>  - If necessary, change the launcher to make sure ExceptionDescribe() is
>>> called
>>> before DestroyJavaVM().
>>>
>>> Does that sound right?
>>>
>>> Regards,
>>> Oliver
>>>
>>> [1]
>>> #include <jni.h>
>>> main() {
>>>    JNIEnv *env;
>>>    JavaVM *jvm;
>>>    jint result;
>>>    jclass cls;
>>>    jmethodID mid;
>>>
>>>    JavaVMInitArgs vmargs;
>>>    vmargs.version = 0x00010002;
>>>    vmargs.nOptions = 0;
>>>    vmargs.ignoreUnrecognized = JNI_TRUE;
>>>
>>>    result=JNI_CreateJavaVM(&jvm, (void**)&env, &vmargs);
>>>
>>>    if (result<0) {
>>>        fprintf(stderr, "Cannot create JavaVM\n");
>>>        exit(1);
>>>    }
>>>
>>>    cls = (*env)->FindClass(env, "TestClass");
>>>
>>>    if(cls == NULL)
>>>    {
>>>        printf("ERROR: FindClass failed.\n");
>>>        goto destroy;
>>>    }
>>>
>>>    mid = (*env)->GetStaticMethodID(env, cls, "main",
>>> "([Ljava/lang/String;)V");
>>>    if(mid==NULL)
>>>    {
>>>        printf("ERROR: GetStaticMethodID call failed.\n");
>>>        goto destroy;
>>>    }
>>>
>>>    (*env)->CallStaticVoidMethod(env, cls, mid, NULL);
>>>
>>> destroy:
>>>    (*jvm)->DestroyJavaVM(jvm);
>>> }
>>>
>>>
>>>
>>> Evgueni Brevnov wrote:
>>> > Hi All,
>>> >
>>> > I'm almost done with the implementation of Invocation API for DRLVM.
>>> > While testing it I ran into a problem when an exception is printed
>>> > twice. I created a simple application which just throws an error and
>>> > it is not handled by any exception handler:
>>> >
>>> > public class Test {
>>> >    public static void main(String [] args) {
>>> >        throw new Error("my");
>>> >    }
>>> > }
>>> >
>>> > In this case the launcher calls env->ExceptionDescribe() before
>>> > destroying VM.  Then it calls DestroyJavaVM() which identifies
>>> > unhanded exception and calls an uncaught exception handler (see
>>> > java.lang.Thread.getUncaughtExceptionHandler()) for the current
>>> > thread. By default the handler prints the exception one more time.
>>> > That's definitely differs from RI where the exception is printed out
>>> > only once.
>>> >
>>> > To identify where the problem is I created another simple test and
>>> > runs it on RI and DRLVM:
>>> >
>>> > public class Test {
>>> >
>>> >    static class MyHandler implements Thread.UncaughtExceptionHandler {
>>> >        public void uncaughtException(Thread t, Throwable e) {
>>> >            System.out.println("My Handler Called!!!");
>>> >        }
>>> >    }
>>> >
>>> >    public static void main(String [] args) {
>>> >        Thread.currentThread().setUncaughtExceptionHandler(new
>>> > MyHandler());
>>> >        throw new Error("my");
>>> >    }
>>> > }
>>> >
>>> > Here is the output:
>>> >
>>> > RI: java.exe Test
>>> > My Handler Called!!!
>>> >
>>> > DRLVM: java.exe Test
>>> > java/lang/Error : my
>>> > at Test.main (Test.java: 12)
>>> > My Handler Called!!!
>>> >
>>> > As you can see RI doesn't print exception stack trace at all. But
>>> > DRLVM does. To be precise the launcher does. So we need to fix the
>>> > launcher.....
>>> >
>>> > Note: The behaviour of DRLVM you have may differ from listed above
>>> > since all experiments were done on my local workspace with Invocation
>>> > API implemented.
>>> >
>>> > ---------------------------------------------------------------------
>>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>> >
>>> >
>>>
>>> -- 
>>> Oliver Deakin
>>> IBM United Kingdom Limited
>>>
>>>
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message