Sorry guys, I've just found different problem at the very same place.
Nik. On 10/11/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:
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 <[EMAIL PROTECTED]> wrote: > Evgueni, > > On 10/11/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > On 9/22/06, Oliver Deakin <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > > > > >>>>> For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>> -- > > > > > > >>>> Oliver Deakin > > > > > > >>>> IBM United Kingdom Limited > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> --------------------------------------------------------------------- > > > > > > >>>> Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > > > >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > >>>> For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>> --------------------------------------------------------------------- > > > > > > >>> Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > > > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > >>> For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Oliver Deakin > > > > > > IBM United Kingdom Limited > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
