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 12:00:05 GMT
Evgueni,
> On 10/11/06, Nikolay Kuznetsov <nikolay.kuznetsov@gmail.com> wrote:
> > 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
>
> I don't understand your concern.... what should we detach? Could you
> give an example or test case?

HARMONY-1816 contains such a test case, it hangs because child thread
works a bit longer than main method. In this case  main method exits,
but the main thread enters
wait for all non daemon treads method. It checks that non daemon count
>1, 1 stands for itself and enters while cycle with condition that
non-daemon threads should be equal to zero, while the main thread also
non-daemon.

> > or rewrite
> > wait_for_all_nondaemon threads to take into account the fact that main
> > thread is also non daemon.
>
> First of all we should not do any assumption regarding main thread. It
> doesn't differ from any other non daemon thread. It may die long
> before last non daemon thread dies. DestroyJavaVM may be called by any
> thread....even unattached...

I agree, but the thread which counts non-daemon threads should take
into account that it itself may also daemon or non-daemon and count
other threads till 1 or 0 or detach(or countdown non-daemon threads)
itself before waiting.

Nik.
>
> Thanks Evgueni
> >
> > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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