harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm] [launcher] Executable hangs
Date Wed, 27 Sep 2006 23:32:54 GMT
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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org

-- 
Gregory Shimansky, Intel Middleware Products Division

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