JNI: printStackTrace() hangs in read()
Tue Feb 4 09:42:00 GMT 2003
this may be a known problem on linux (kernel 2.4.18; RH8; gcc3.2.1, no
I have run a simple java test program which simply calls
The interesting problem is that this works with cni but not with jni; with
cni (or when you give the --main parameter) the program creates a new thread
running the test program while jni attaches to the java vm and then runs the
test in the main process.
I've traced it down to the natCreatePosixProcess (or similar) where it forks
and then execvp's the c++filt. It seems that the fork works, the child is
created and exec has replaced the program code (at least the following
sleep(1) statement is never called). But if I strace -ff then I don't see
an exec call, the last thing I see is a munmap and a following write(4,..).
I don't know where the write comes from, there should be a sleep(1) when the
exec has failed.
When I strace the cni call, I see an additional close, getpid, set/getrlimit
sequence in the child (these statements are called before the first
sleep(1), but I have no idea where they come from -- from the threads
On linux, is is possible to fork/exec when threads are being used (there are
two other threads probably belonging to the gc and finalizer)? How can I
determine if a procid is a thread?
What could be the reason that glibc has replaced the child's code but in the
strace output I don't see an exec call?
More information about the Java