Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (idunn.apache.osuosl.org: domain gmail.com designates
 66.249.92.169 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=e3rjanCePJxzMEQ3aq15TyNB5aENbtNusA9dRw3vQ8uqPVebQS0uC8pBNlmgIHZZ1mQ0+dLM1ViQppxZmEx26ov1yNcTi/3KI2qPnUUAUtMN4DD+ubeT3dE6HKPI7VOrOMLajnCP84B2JVVuQ+wf94K1hb8uUjVhzYtxTUVLx2Q=
Message-ID: <4512AF1E.1040109@gmail.com>
Date: Thu, 21 Sep 2006 16:26:22 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] Should the launcher print uncaught exceptions?
References: <e29119980609210001o59b2f252s85e4b8d451a80ff6@mail.gmail.com>
	 <45125C1A.9010707@googlemail.com>
 <e29119980609210520l2e951144j4fbef84be47fdb8b@mail.gmail.com>
 <45129FCE.20104@googlemail.com>
In-Reply-To: <45129FCE.20104@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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