harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgueni Brevnov" <evgueni.brev...@gmail.com>
Subject Re: [drlvm] Should the launcher print uncaught exceptions?
Date Wed, 11 Oct 2006 12:09:26 GMT
Nikolay,

>From what you said above I conclude that it is TM problem in respect
to how it manages non-daemon threads. Do you agree? If you don't
please start another thread with appropriate subject. It seems to be
out of current topic.

Evgueni

On 10/11/06, Nikolay Kuznetsov <nikolay.kuznetsov@gmail.com> wrote:
> 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
>
>

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