I have been trying to follow this thread as best as possible. I apologize if this has already been addressed.
Does anyone else have the problem of the executable just hanging? I know some people had this problem before, but I wasn't sure what the fix ended up being (if there was one). Here is the problem I am seeing: When I run ./java it runs fine (after I comment out the assertion on line 183 of thread_native_fat_monitor.c). When I try to run ./java helloworld, it just hangs and I have to kill the process. I investigated this a little bit, and I found that it hangs on the call to FindClass (in main.c line around line 1199). I am unable debug with gdb also, so I have resorted to printf's, and in jni.cpp, I found the definition of FindClass, and put an printf to see what class it is trying to find when it hangs. I see the following: Line 478 in jni.cpp: inside JNICALL FindClass: java/lang/Thread Also, when I run ./java -Xtrace:em, I get the following (and it hangs): ... EM: compile start:[JET_DPGO n=802] java/lang/Thread::join()V EM: compile done:[JET_DPGO n=802: OK] java/lang/Thread::join()V EM: compile start:[JET_DPGO n=803] java/lang/Object::wait()V EM: compile done:[JET_DPGO n=803: OK] java/lang/Object::wait()V Line 478 in jni.cpp: inside JNICALL FindClass: java/lang/Thread Again, it seems to always hang after FindClass is called for java/lang/Thread. I have tried setting LD_LIBRARY_PATH as suggested earlier. I also have JAVA_HOME set (and I have tried it with it unset). Everything seems to have the same behavior. [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ echo $LD_LIBRARY_PATH /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/:/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ echo $JAVA_HOME /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre I am using Gentoo Linux. Any ideas? Thanks, Armand Gregory Shimansky wrote: > On Friday 22 September 2006 14:31 Egor Pasko wrote: > >> what makes me really nervous is that I cannot debug in GDB on Linux >> (!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!) >> >> When GDB starts, it becomes broken right after the start: >> [New Thread 1080397952 (LWP 13879)] >> [New Thread 1083603888 (LWP 13882)] >> Cannot find user-level thread for LWP 13879: generic error >> >> Did anybody come across this problem recently? I googled a little, but >> could not find any valuable comments. I remember, there was no such >> problem in older days!! Is that our new ThreadManager that does things >> like this? or is it something else? >> > > I've seen in another thread. The problem with gdb is caused because process > reexecs itself with new environment (there is no other way known to tell > dynamic linker to use a library path). This is new launcher feature necessary > to get rid of java shell script and use a real executable. > > Ivan Volosyuk investigated the conditions when launcher performs execing > itself to set LD_LIBRARY_PATH and it appears (unless fixed recently) that you > need to set LD_LIBRARY_PATH=<HDK path>/bin/:<HDK path>/bin/default. Don't > forget a tailing slash in the first path :) > > Anyway, to get the correct LD_LIBRARY_PATH which launcher wants you can get > it > from /proc/`pidof java`/environ if you launch a simple java program and catch > its reexeced environment. If LD_LIBRARY_PATH contents is equal to what > launcher wants, reexecing doesn't happen and this allows normal debugging. > > I think we should document this since it is going to stay for a long time and > is really required for development on Linux. > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
