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
(!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!)
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
