Hmm never saw it hanging at this point. It looks like a java class loader starts on loading a j.l.Thread class and somehow deadlocks or waits for something. I would try to get a stack trace in the first place, evaluating st_print() in debugger but it doesn't always work correctly.
Can anyone else suggest a way to debug this problem? On Wednesday 27 September 2006 09:35 Armand Navabi wrote: > Gregory Shimansky wrote: > > I think not. DRLVM needs its own threading library. The reason is > > discussed in a separate thread "thread library - let there be one". I am > > not sure I understand all the reasoning for separate libhythr.so > > implementation, but I know the drlvm version should be in bin/ and > > bin/default/ directories. > > Ok, I read that thread. Is there an easy temporary fix to this? > > > What is the reason to set breakpoint in jni.cpp:478? It is a condition > > that if JNI FindClass is called in exception state it shouldn't do > > anything, just return NULL. > > I'm sorry, my line 478 is different than yours, because I have other > prints and things in there. I was not putting the breakpoint on the > line that checks if it is called in exception state. Basically, I just > put a print inside of that procedure because I traced the hanging to > that method (or so I thought). My point was that I am unable to > breakpoints anywhere in jni.cpp. Below you have explained what problem > that is related to. And as far as tracing, you have suggested a much > more efficient way to trace where it is going in the code. Thanks. > > >> Make breakpoint pending on future shared library load? (y or [n]) y > >> > >> And then when I run the program it never stops at the breakpoint, though > >> I see the print I have inserted in the code. Secondly, and more > >> importantly, if I try to do anything interesting, like run helloworld, > >> gdb seems to lose a thread and then hang (says it Cannot find a thread. > >> Invalid thread handle). I have to then stop it and go kill it. > > > > The solution for this was found and discussed in thread "APR fails to > > load a JIT library when using a fully qualified path". The launcher execs > > itself with a new environment setting for LD_LIBRARY_PATH and gdb cannot > > work around this. > > I reread those threads and it seems some changes were suggested. Have > these changes been made. I couldn't see (or perhaps couldn't figure > out) any way to quickly fix this from the discussions. It seemed as > though people were suggesting moving and merging libraries. If it has > been fixed, I should have it because I have recently updated. > > > I have a proposal for you. Run "java -Xthread -Xtrace Hello" for hello > > world application. The -Xtrace option will produce a lot of output but it > > will enable all debugging tracing in drlvm and when it hangs for you it > > will be a very close location to the reason of the problem. If there is > > no output with -Xtrace, then it probably means launcher problems. Please > > update the sources, some launcher problems were resolved just recently > > I updated all the classlib and drlvm code earlier today. Just to make > sure we are talking about the same thing here, I have compiled > helloworld.java separately with Sun's compiler and then I made sure it > ran (it runs both with Sun's java and the classlib with IBM's VM), and > then I moved it to the drlvm's bin directory. > > There is no particular Hello application you are talking about correct? > The application I am running was a java program I wrote myself and > compiled. > > And then I tried to run my hello world application as you said. Like > you said it produced a lot of output and towards the end when it hanged, > this is the last output it produced: > > [0x4000] : Looking for native: > java/lang/VMThreadManager.start(Ljava/lang/Thread;JZI)I > [0x4000] : trying: Java_java_lang_VMThreadManager_start > [0x4000] : Compiled method > java/lang/VMThreadManager.start(Ljava/lang/Thread;JZI)I, entry 0xb68a4000 > [0x4000] : GetObjectClass called > [0x4000] : GetObjectClass: class = java/lang/FinalizerThread > [0x4000] : GetFieldID called > [0x4000] : GetFieldID java/lang/FinalizerThread.vm_thread J = 0x8286894 > [0x4000] : GetLongField called, id = 0x8286894 > [0x4000] : IsInstanceOf called > [0x4000] : GetObjectClass called > [0x4000] : GetObjectClass: class = java/lang/FinalizerThread > [0x8003] : gc_thread_init 0x807d720 > [0x8003] : FindClass called, name = java/lang/Thread > [0x8003] : FindClass called, name = java/lang/Thread > [0x8003] : si_goto_previous from ip = (nil) (M2N) > [0x8003] : si_unwind_from_m2n, ip = (nil) > [0x8003] : si_goto_previous to ip = (nil) (M2N) > [0x8003] : StartLoading class java/lang/Thread with loader 0x8633a18 > [0x8003] : 0x8633a18 0x807d660 I java/lang/Thread > [0x8003] : Loader U (0x8633a18) loading class: java/lang/Thread... > [0x8003] : enter method java/lang/ClassLoader loadClass > (Ljava/lang/String;)Ljava/lang/Class; > > At this point, it hangs, and I am forced to Cntrl^c to kill the process. > > > Thanks, > Armand > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Shimansky, Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
