process shutdown fails in JNI-application (native threads)

[Volker Wehner]

Hi, 
I am using the JNI invocation API in a C (not C++) application. Calling java methods 
works. But when the program calls exit() it hangs in __syscall_sigsuspend(). All 
threads (native ones, creates by the JVM after JNI_CreateJavaVM()) remain in the 
process list. This is the stack of the main thread:
(gdb) bt
#0  0x4017af74 in __syscall_sigsuspend ()
#1  0x4019f4cc in __DTOR_END__ ()
#2  0x4010061d in pthread_exit_process (retcode=0, arg=0x0) at restart.h:32
#3  0x401256aa in exit (status=0) at exit.c:52
#4  ...


I think this in not a problem of my application, as the same effect occurs with 
appletviewer:
$ rm -rf $HOME/.hotjava
$ appletviewer &# the licence window appears
# press [accept] button (nothing happens)
# press it again (window disappears)
# appletviewer ends with a usage message
$ ps# lists 9 threads 
27370  p8 S0:00 sh /usr/lib/java/bin/../bin/i686/native_threads/appletviewer
27390  p8 S0:00 /usr/lib/java/bin/../bin/i686/native_threads/java sun/applet
27391  p8 S0:00 /usr/lib/java/bin/../bin/i686/native_threads/java sun/applet
27392  p8 S N  0:00 /usr/lib/java/bin/../bin/i686/native_threads/java sun/applet
27393  p8 S0:00 /usr/lib/java/bin/../bin/i686/native_threads/java sun/applet
27394  p8 S0:00 /usr/lib/java/bin/../bin/i686/native_threads/java sun/applet
27395  p8 S N  0:00 /usr/lib/java/bin/../bin/i686/native_threads/java sun/applet
27396  p8 S N  0:00 /usr/lib/java/bin/../bin/i686/native_threads/java sun/applet
27397  p8 S0:00 /usr/lib/java/bin/../bin/i686/native_threads/java sun/applet
27398  p8 S N  0:00 /usr/lib/java/bin/../bin/i686/native_threads/java sun/applet


here are 2 of the stacks, all are similar to each other and 
to the stack of my program:


$ gdb /usr/lib/java/bin/../bin/i686/native_threads/java
(gdb) atta 27390
Attaching to program `/usr/lib/java/bin/../bin/i686/native_threads/java', process 27390
Reading symbols from /usr/lib/java/bin/../lib/i686/native_threads/libjava.so...
done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /usr/lib/java/bin/../lib/i686/native_threads/libawt.so...
done.
Reading symbols from /usr/X11R6/lib/libXpm.so.4...done.
Reading symbols from /usr/X11R6/lib/libXt.so.6...done.
Reading symbols from /usr/X11R6/lib/libICE.so.6...done.
Reading symbols from /usr/X11R6/lib/libSM.so.6...done.
Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /usr/X11R6/lib/libXp.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_files.so.1...done.
Reading symbols from /lib/libnss_nis.so.1...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /lib/libnss_dns.so.1...done.
Reading symbols from /lib/libresolv.so.2...done.
0x40281f74 in __syscall_sigsuspend ()
(gdb) bt
#0  0x40281f74 in __syscall_sigsuspend ()
#1  0x402a64cc in __DTOR_END__ ()
#2  0x40077bef in pthread_join (thread_id=1025, thread_return=0xb4c8)
at restart.h:49
#3  0x4005c598 in java_main ()
at ../../../../src/genunix/java/native_threads/src/threads_md.c:1201
#4  0x8061dc6 in main (argc=2, argv=0xb5a4, envp=0xb5b0)
at ../../../../src/genunix/java/javai/java.c:23
(gdb) deta
Detaching from program: /usr/lib/java/bin/../bin/i686/native_threads/java proces
s 27390

(gdb) atta 27392
(gdb) bt 
#0  0x40281f74 in __syscall_sigsuspend ()
#1  0x402a64cc in __DTOR_END__ ()
#2  0x40077383 in pthread_cond_wait (cond=0x81988bc, mutex=0x8198890)
at restart.h:49
#3  0x4005c656 in condvarWait ()
at ../../../../src/genunix/java/native_threads/src/condvar_md.c:191
#4  0x4005b5c1 in sysMonitorWait ()
at ../../../../src/genunix/java/native_threads/src/monitor_md.c:128
#5  0x4005c1cb in WaitToDie ()
at ../../../../src/genunix/java/native_threads/src/threads_md.c:364
#6  0x40057c17 in thread_java_main ()
at ../../../../src/genunix/java/javai/javai.c:142
#7  0x4005c4d8 in java_start ()
at ../../../../src/genunix/java/native_threads/src/threads_md.c:1200
#8  0x40078106 in pthread_start_thread (arg=0xbf9ffea4) at manager.c:165



I am using DLD Distribution Version 4.17.0.4, blackdown jdk1.1.7v3, 
THREADS_FLAG=native, libc-2.0.7.so, ld-2.0.7.so, libpthread-0.7.so 

There is a warning from ldconfig -D: /lib/libpthread-0.7.so has inconsistent soname 
(libpthread.so.0), I don't know, if this can be ignored. 

Can anybody help me ? 


Regards
Volker


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Newbie question

[Volker Wehner]

Pere Serra wrote:
> 
> I have an easy question:
> What's the difference between native threads and green theads?
> Which one is more eficient/stable?
> 

(from blackdown:)

Native threads use the operating system to do the task switching.

Native threads are thus a benefit in multi-processor (SMP) systems
and they tend to make native method invocation support easier to
deal with.

Native threads do have some limitations relative to green threads.
They require more overhead and are limited to the number of processes
your Linux kernel supports.

Note, that while the native threads support works very well and has
been tested by the Java-Linux porting team, it should still be viewed
as "beta" code as it has not had the extended testing that the
green threads code has. (November 98)

Also, at this time there is no native threads support for libc5 systems.
Only glibc based Linux systems.


Native Threads vs Green Threads
---

This release includes both green and native threads.  Green threads are
user based theads that have been part of the JDK since its inception.
Green threads  are very stable, have a lower memory footprint, and
involve much lower overhead for creation and context switching.

Native threads are linux threads (one-to-one implementation of pthreads)
and are kernel based.  Each thread is basically a clone of the its
parent process and therefore has a higher overhead for context
switching and creation and a larger memory footprint.  Because they
are processes, the number of threads is limited by the number of
processes/tasks built into the Linux kernel. You will have to recompile
your kernel to handle larger number of threads.

So why use native threads? Native threads deal better with some JNI
native C programs than green_threads because you do not have to make
all io non-blocking and therefore do not have to redefine all of the
system calls related to io.  But the main reason to use native
threads is that on multi-processor systems, native threads can be
easily split among processors greatly improving performance while
green_threads can not.  Although on single processor systems, green
threads will probably be faster for most programs.



Volker


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]