JNI: printStackTrace() hangs in read()

Jost Boekemeier JBoekemeier@inetsoftware.de
Tue Feb 4 09:42:00 GMT 2003


Hi,

this may be a known problem on linux (kernel 2.4.18; RH8; gcc3.2.1, no
special options)

I have run a simple java test program which simply calls
ex.printStackTrace().

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.


//child
sleep(1)
execvp(c++filt, args)
sleep(1)
exit(127)

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
package)?


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?


Jost



More information about the Java mailing list