harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Gorr" <vvg...@gmail.com>
Subject Re: [drlvm] Trouble Building DRLVM
Date Fri, 22 Sep 2006 10:53:37 GMT
On 22 Sep 2006 17:31:41 +0700, Egor Pasko <egor.pasko@gmail.com> wrote:
>
> On the 0x1EB day of Apache Harmony Egor Pasko wrote:
> > On the 0x1EB day of Apache Harmony Geir Magnusson, Jr. wrote:
> > > I modified the launcher to include both the vm directory as well as
> > > the launcher directory on the PATH/LD_LIBRARY_PATH.
> >
> > I am not catching .. the launcher directory is known without
> > PATH/LD_LIBRARY_PATH. Why should we look at PATH?
> >
> > > Can those that have been having troubles with shared lib loading give
> > > it a try, and report back, and please mention the platform you are
> > > running on...
> >
> > SUSE 9:
> > * HelloWorld works without complaining, cool!
> > * JAVA_HOME crash is gone, great!
> >   (but are we not ignoring JAVA_HOME yet?)
> > * tests:
> >   * ThreadTest failed on JET (looks like a known issue:)
> >   * ~4 tests failed on OPT (ThreadTest too), I'll look at them
>
> I picked the ClassLoaderTest. It passes on JET and failes on OPT.
> Looks like it is time to open a JIRA...  If nobody objects, :) I'll
> put some words here as an example how to investigate JIT compiler
> problems. I hope, it might be useful for people.
>
> I ran it as a single test like this:
> .../jre/bin/java -Xem:opt
>
> -Xbootclasspath/a:$HARMONY/working_classlib/depends/jars/junit_3.8.2/junit.jar:$HARMONY/working_vm/build/lnx_ia32_gcc_debug/semis/kernel.tests/classes
> junit.textui.TestRunner java.lang.ClassLoaderTest
>
> If invoked with the option "-Xtrace:em", DRLVM prints compilation
> events as soon as they occur. What makes real fun is that one method
> starts compilation several times (without success) and receives
> SEGFAULT after not so many attempts. The bug may be in OPT or in
> recompilation, not clear now. Will investigate (first, I'll try to
> compile some methods with JET selectively)
>
> The strangest piece of the trace looks like this (funny, huh?)
>
> EM: compile done:[CS_OPT n=919: OK] java/lang/Object::wait()V
> EM: compile start:[CS_OPT n=921] java/io/FileOutputStream::finalize()V
> EM: compile start:[CS_OPT n=922]
> java/lang/ThreadGroup::remove(Ljava/lang/Thread;)V
> EM: compile start:[CS_OPT n=923]
> java/lang/ThreadGroup::remove(Ljava/lang/Thread;)V
> EM: compile start:[CS_OPT n=924]
> java/lang/ThreadGroup::remove(Ljava/lang/Thread;)V
> EM: compile start:[CS_OPT n=925]
> java/lang/ThreadGroup::remove(Ljava/lang/Thread;)V
> EM: compile start:[CS_OPT n=926]
> java/lang/ThreadGroup::remove(Ljava/lang/Thread;)V
> EM: compile start:[CS_OPT n=927]
> java/lang/ThreadGroup::remove(Ljava/lang/Thread;)V
> EM: compile start:[CS_OPT n=928]
> java/lang/ThreadGroup::remove(Ljava/lang/Thread;)V
> SIGSEGV in VM code.
> EM: compile done:[CS_OPT n=920: OK]
> java/nio/channels/spi/AbstractInterruptibleChannel::close()V
> EM: compile start:[CS_OPT n=929]
> org/apache/harmony/nio/internal/FileChannelImpl::implCloseChannel()V
> Stack trace:
>        1: ?? (??:-1)
> <end of stack trace>
> Segmentation fault
>
> with -Xno_parallel_jit option (re)compilation order should be somewhat
> different, and here it is:
>
> EM: compile done:[CS_OPT n=915: OK] java/util/zip/ZipFile::finalize()V
> EM: compile start:[CS_OPT n=917] java/util/zip/ZipFile::close()V
> EM: compile done:[CS_OPT n=916: OK] java/lang/Object::wait()V
> EM: compile start:[CS_OPT n=918] java/util/zip/ZipFile::close()V
> EM: compile start:[CS_OPT n=919] java/util/zip/ZipFile::close()V
> EM: compile start:[CS_OPT n=920] java/util/zip/ZipFile::close()V
> EM: compile start:[CS_OPT n=921] java/util/zip/ZipFile::close()V
> EM: compile start:[CS_OPT n=922] java/util/zip/ZipFile::close()V
> EM: compile start:[CS_OPT n=923] java/util/zip/ZipFile::close()V
> EM: compile start:[CS_OPT n=924] java/util/zip/ZipFile::close()V
> EM: compile start:[CS_OPT n=925] java/util/zip/ZipFile::close()V
> SIGSEGV in VM code.
> Stack trace:
>    1: ?? (??:-1)
> <end of stack trace>
>
> what makes me really nervous is that I cannot debug in GDB on Linux
> (!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!)


Why not to reproduce this situation on Windows and not to use the MVS
debugger?
IIRC this problem also exists for Windows.

Thanks,
Vladimir.


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?
>
> --
> Egor Pasko, Intel Managed Runtime 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message