You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Gregory Shimansky (JIRA)" <ji...@apache.org> on 2007/06/07 17:11:26 UTC
[jira] Commented: (HARMONY-4078) [drlvm][kernel] Runtime.exec()
hangs on Linux
[ https://issues.apache.org/jira/browse/HARMONY-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502376 ]
Gregory Shimansky commented on HARMONY-4078:
--------------------------------------------
With this patch kernel test java.lang.RuntimeTest2 starts to fail. 3 of its test cases get an exception.
> [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
> Assignee: Gregory Shimansky
> Attachments: drlvm_runtime_exec_fix.patch
>
>
> 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.