harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Popov (JIRA)" <j...@apache.org>
Subject [jira] Created: (HARMONY-4078) [drlvm][kernel] Runtime.exec() hangs on Linux
Date Wed, 06 Jun 2007 16:42:26 GMT
[drlvm][kernel] Runtime.exec() hangs on Linux
---------------------------------------------

                 Key: HARMONY-4078
                 URL: https://issues.apache.org/jira/browse/HARMONY-4078
             Project: Harmony
          Issue Type: Bug
          Components: DRLVM
         Environment: Linux/x86, harmony-jdk-r544741
            Reporter: Ivan Popov


I noticed CC run for jdktools tests often hangs or times out in running JPDA tests on a single-cpu
Linux/x86 machine (1xPentium4, 3.00GHz, SLES9 32-bit). Also I noticed Runtime.exec() hangs
also in execution "svn info" in self-histing HDK build scenario on that machine. On other
multi-cpu machines tests usually pass. 

CC run times out because some random JPDA tests hangs. Attaching with gdb shows that JPDA
test hangs in Runtime.exec() while launching debuggee VM process. In more details, it hangs
in DRLVM kernel class function Java_java_lang_Runtime_00024SubProcess_createProcess0():

(gdb) where
#0  0xffffe410 in ?? ()
#1  0xbfffcedc in ?? ()
#2  0x00000004 in ?? ()
#3  0xbfffce60 in ?? ()
#4  0x406379db in __read_nocancel () from /lib/tls/libc.so.6
#5  0x40c1ffcb in Java_java_lang_Runtime_00024SubProcess_createProcess0 (env=0x80c12f8, obj=0xbfffcf04,
    cmdarray=0xbfffcf08, envp=0x0, dir=0x0, la=0xbfffcf14)
    at /export/users/ipopov1/svn_harmony_federated/trunk/working_vm/vm/vmcore/src/kernel_classes/native/Runtime_lnx.cpp:221
#6  0x52e64315 in ?? ()
<...>

This function hangs in reading data from pipe to the forked child process, but child process
does not send any data. Attaching gdb to child process shows the following stack trace:

#0  0xffffe410 in ?? ()
#1  0xbfffcc2c in ?? ()
#2  0x0000000b in ?? ()
#3  0x00000000 in ?? ()
#4  0x4079c896 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
#5  0x406511b3 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libc.so.6
#6  0x4003d622 in os_cond_timedwait (cond=0x806a280, mutex=0x806a2b0, ms=0, nano=0)
    at .../trunk/working_vm/vm/thread/src/linux/os_condvar.c:42
#7  0x4003f87d in condvar_wait_impl (cond=0x806a280, mutex=0x806a2b0, ms=0, nano=0, interruptable=0)
    at .../trunk/working_vm/vm/thread/src/thread_native_condvar.c:55
#8  0x40041231 in sem_wait_impl (sem=0x806a278, ms=0, nano=0, interruptable=0)
    at .../trunk/working_vm/vm/thread/src/thread_native_semaphore.c:70
#9  0x40041304 in hysem_wait (sem=0x806a278)
    at .../trunk/working_vm/vm/thread/src/thread_native_semaphore.c:107
#10 0x400417ad in thread_safe_point_impl (thread=0x806a150)
    at .../trunk/working_vm/vm/thread/src/thread_native_suspend.c:137
#11 0x400416fb in hythread_safe_point_other (thread=0x806a150)
    at .../trunk/working_vm/vm/thread/src/thread_native_suspend.c:110
#12 0x40c7baf6 in hythread_suspend_disable () at hythread_ext.h:424
#13 0x40c754fa in GetArrayLength (jni_env=0x80c12f8, array=0xbfffcf08)
    at .../trunk/working_vm/vm/vmcore/src/jni/jni_array.cpp:47
#14 0x40c20926 in JNIEnv_External::GetArrayLength (this=0x80c12f8, array=0xbfffcf08) at jni.h:1454
#15 0x40c1fb1e in Java_java_lang_Runtime_00024SubProcess_createProcess0 (env=0x80c12f8, obj=0xbfffcf04,
    cmdarray=0xbfffcf08, envp=0x0, dir=0x0, la=0xbfffcf14)
    at .../trunk/working_vm/vm/vmcore/src/kernel_classes/native/Runtime_lnx.cpp:147
#16 0x52e64315 in ?? ()
<...>

Looking at the sources shows that child process hangs right after forking but before executing
new binary. In this interval it calls JNI functions to obtain info from arguments and hangs
in JNI implementation. I suspect this is because JNi functions are invoked from the new forked
process, and I believe it is not correct.

I modified  this function to get all JNI data before forking new process and this solved problems
with JPDA tests.
I'm attaching patch, please review it and apply.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message