You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Ivan Popov (JIRA)" <ji...@apache.org> on 2007/06/06 18:42:26 UTC
[jira] Created: (HARMONY-4078) [drlvm][kernel] Runtime.exec() hangs
on Linux
[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.
[jira] Updated: (HARMONY-4078) [drlvm][kernel] Runtime.exec() hangs
on Linux
Posted by "Ivan Popov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ivan Popov updated HARMONY-4078:
--------------------------------
Attachment: drlvm_runtime_exec_fix.patch
This patch 'drlvm_runtime_exec_fix.patch' moves all JNI calls before fork(). This eliminates invocation of JNI functions from the forked child process.
> [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
> 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.
[jira] Commented: (HARMONY-4078) [drlvm][kernel] Runtime.exec()
hangs on Linux
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502419 ]
Gregory Shimansky commented on HARMONY-4078:
--------------------------------------------
I think I've found the cause for failure. In the code ReleaseStringUTFChars is mistakenly done on cmdDir instead of str. Now the test passes for me. If all other tests work, I'll commit a modified patch.
> [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.
[jira] Closed: (HARMONY-4078) [drlvm][kernel] Runtime.exec() hangs
on Linux
Posted by "Ivan Popov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ivan Popov closed HARMONY-4078.
-------------------------------
Thanks, Gregory. Verified in harmony-jdk-r545480, now both JPDA tests and HDK self-hosting build pass on that Linux machine. Closing this issue.
> [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.
[jira] Assigned: (HARMONY-4078) [drlvm][kernel] Runtime.exec()
hangs on Linux
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregory Shimansky reassigned HARMONY-4078:
------------------------------------------
Assignee: Gregory Shimansky
> [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.
[jira] Commented: (HARMONY-4078) [drlvm][kernel] Runtime.exec()
hangs on Linux
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Resolved: (HARMONY-4078) [drlvm][kernel] Runtime.exec()
hangs on Linux
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregory Shimansky resolved HARMONY-4078.
----------------------------------------
Resolution: Fixed
I applied a slightly modified patch to Runtime_lnx.cpp. It uses ReleaseStringUTFChars on a correct pointer and also frees malloced memory in parent process. Patch applied at 545255. Please check that it helps with dead lock.
> [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.
[jira] Updated: (HARMONY-4078) [drlvm][kernel] Runtime.exec() hangs
on Linux
Posted by "Ivan Popov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ivan Popov updated HARMONY-4078:
--------------------------------
Patch Info: [Patch Available]
> [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
> 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.