harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nikolay Kuznetsov" <nikolay.kuznet...@gmail.com>
Subject Re: [drlvm] Should the launcher print uncaught exceptions?
Date Wed, 11 Oct 2006 10:06:09 GMT
I have a quick note about detaching current thread. I've filled
HARMONY-1816 issue about counting non daemon threads. And concerning
DetachCurrentThread we should either detach it or rewrite
wait_for_all_nondaemon threads to take into account the fact that main
thread is also non daemon.

Nik.
On 10/11/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> Oliver,
>
> I created https://issues.apache.org/jira/browse/HARMONY-1819 with
> suggested fix. Please, look at and update it if DetachCurrentThread is
> required before DestroyJavaVM for some reason.
>
> Thanks
> Evgueni
>
> On 9/22/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> > On 9/22/06, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> > > Tim Ellison wrote:
> > > > 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.
> > > >
> > >
> > > Yes, that surprised me too. The bug suggests that the launcher is at
> > > fault for calling
> > > ExceptionDescribe() instead of DetachCurrentThread(). However I would have
> > > thought that this was not necessary in the case where an exception
> > > handler has
> > > been registered, and that the handler would be called during
> > > DestroyJavaVM()'s
> > > execution.
> > >
> > > Perhaps this is something that could be "fixed" in DRLVM? So if
> > > DetachCurrentThread() is called, it runs any registered exception
> > > handlers for that
> > > thread as usual. However, if DestroyJavaVM is called, it makes sure that all
> > > exception handlers are run for every thread.
> > >
> >
> > Sure, I checked both cases work fine on my implementation of
> > InvocationAPI for DRLVM (with DetachCurrentThread and without it). So
> > the launcher can choose either to detach the main thread or not...
> >
> > Thanks
> > Evgueni
> >
> > > Regards,
> > > Oliver
> > >
> > > > 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
> > > >>>
> > > >>>
> > > >>>
> > > >
> > > >
> > >
> > > --
> > > 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
>
>

---------------------------------------------------------------------
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