harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm] [launcher] Executable hangs
Date Wed, 27 Sep 2006 11:32:04 GMT
FWIW, Thanks for sticking with us on this.

I'm sure we'll find it.


On Sep 27, 2006, at 1:35 AM, 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: 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

View raw message