On the 0x1EC day of Apache Harmony Vladimir Gorr wrote: > On 22 Sep 2006 17:31:41 +0700, Egor Pasko <[EMAIL PROTECTED]> 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.
I love Linux. And many other people do. We should be happy debuggers -- Egor Pasko, Intel Managed Runtime Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
