[Bug libgcj/13212] New: AttachCurrentThread() not working

[Bug libgcj/13212] New: AttachCurrentThread() not working

[alessio at itapac dot net]

Every version of GCC with Java support <= 3.3.2 I have tried (3.3.2, 3.3.1, 3.1)
doesn't handle the AttachCurrentThread call working with native code. The bug is
similar to the one reported for Kaffe that can be found searching on google. 
Here's a gcc -v:
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/specs
Configured with: /var/tmp/portage/gcc-3.3.2-r2/work/gcc-3.3.2/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3
--includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info --enable-shared
--host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib
--enable-languages=c,c++,f77,objc,java --enable-threads=posix --enable-long-long
--disable-checking --enable-cstdio=stdio --enable-clocale=generic
--enable-__cxa_atexit --enable-version-specific-runtime-libs
--with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/g++-v3
--with-local-prefix=/usr/local --enable-shared --disable-nls
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--enable-interpreter --enable-java-awt=xlib --with-x --disable-multilib
Thread model: posix
gcc version 3.3.2 20031022 (Gentoo Linux 3.3.2-r2, propolice)

The behaviour is simple to reproduce: try using this (anyway the bug applies to
JNI interface too)

--hello.cc start--

#include <gcj/cni.h>
#include "hello.h"
#include <iostream>
#include <pthread.h>

using namespace std;
using namespace java::lang;

static pthread_t attachable;
void * subStart(void *th) {
                cerr << "Before attach" << endl;
                jstring threadName = (jstring)th;

                Thread *tp = JvAttachCurrentThread(NULL, NULL);
                cerr << "I am attached" << endl;
                int i = 0;
                while(1)  {
                        cerr << "detached for " << i++ << " quarters" <<endl;
                        usleep(50000);
                }
}
void *subStop(void *null) {
                JvDetachCurrentThread();
                cerr << "I am detached" << endl;
}

void ::hello::start() {
        cerr << "I am in start()" << endl;
        cerr << "Result is " << (int)JvCreateJavaVM(NULL) << endl;
        jstring zocchia = JvNewStringUTF("suka");
        JvAttachCurrentThread(NULL, NULL);
        pthread_create(&attachable, NULL,  subStart, (void *)zocchia);
}

void ::hello::stop() {
        cerr << "I am in stop()" << endl;
        pthread_cancel(attachable);
        pthread_join(attachable, NULL);
        cerr << "Joined!"<< endl;
}

--hello.cc stop--

--hello.java start--
import java.io.*;

class hello {
        public native void start();
        public native void stop();


        static {
        //      System.loadLibrary("hello");
        }

        public static void main(String[] argv) throws Exception {
                hello z = new hello();
                z.start();
                Thread.sleep(2000);
                z.stop();
                System.out.println("Thread stopped");
        }
}
--hello.java stop--

Upon AttachCurrentThread the program gets killed by a SIGSEGV.
GDB session detectes the problem is:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1102085424 (LWP 17776)]
GC_local_malloc_atomic (bytes=32)
    at ../../../gcc-3.3.2/boehm-gc/linux_threads.c:361
361             ptr_t my_entry = *my_fl;
(gdb) bt
#0  GC_local_malloc_atomic (bytes=32)
    at ../../../gcc-3.3.2/boehm-gc/linux_threads.c:361
#1  0x40448d9e in _Jv_AllocPtrFreeObject (klass=0x4, size=32) at java-gc.h:53
#2  0x40470180 in _Jv_AllocString (len=16)
    at ../../../gcc-3.3.2/libjava/java/lang/natString.cc:399
#3  0x404701c2 in _Jv_NewString (chars=0x4, len=16)
    at ../../../gcc-3.3.2/libjava/java/lang/natString.cc:414
#4  0x4047257c in java::lang::Thread::gen_name() () at cni.h:52
#5  0x4047271b in _Jv_AttachCurrentThread (name=0x0, group=0x0)
    at ../../../gcc-3.3.2/libjava/java/lang/natThread.cc:406
#6  0x08049196 in JvAttachCurrentThread(java::lang::String*,
java::lang::ThreadGroup*) ()
#7  0x08048f00 in subStart(void*) ()
#8  0x408e1332 in start_thread () from /lib/tls/libpthread.so

-- 
           Summary: AttachCurrentThread() not working
           Product: gcc
           Version: 3.3.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libgcj
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: alessio at itapac dot net
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-linux-gnu
  GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212

[Bug libgcj/13212] AttachCurrentThread() not working

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2003-11-27 16:30 -------
I can confirm it on a target that uses pthread (powerpc-apple-darwin):
#0  GC_local_gcj_malloc (bytes=40, ptr_to_struct_containing_descr=0x2531cc) at /Volumes/
UFS_Partition/pinskia/src/fsf/gcc-clean/src/boehm-gc/pthread_support.c:353
#1  0x0005f7a4 in _Jv_AllocObjectNoFinalizer (klass=0x25321c, size=40) at ./include/java-gc.h:
38
#2  0x0005f7f8 in _Jv_AllocObject (klass=0x25321c, size=72) at /Volumes/UFS_Partition/pinskia/
src/fsf/gcc-clean/src/libjava/prims.cc:421
#3  0x0006a398 in _Jv_AllocString (len=8) at /Volumes/UFS_Partition/pinskia/src/fsf/gcc-clean/
src/libjava/gcj/javaprims.h:461
#4  0x0006a65c in _Jv_NewString (chars=0xf0101d84, len=8) at /Volumes/UFS_Partition/pinskia/
src/fsf/gcc-clean/src/libjava/java/lang/natString.cc:431
#5  0x000692ac in java::lang::Thread::gen_name() () at /Volumes/UFS_Partition/pinskia/src/fsf/
gcc-clean/src/libjava/gcj/cni.h:52
#6  0x00069438 in _Jv_AttachCurrentThread (name=0x0, group=0x0) at /Volumes/UFS_Partition/
pinskia/src/fsf/gcc-clean/src/libjava/java/lang/natThread.cc:406
#7  0x000027f4 in JvAttachCurrentThread(java::lang::String*, java::lang::ThreadGroup*) 
(name=0x0, group=0x0)
#8  0x00002724 in subStart(void*) (th=0x10754a0)
#9  0x900247e8 in _pthread_body ()

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-11-27 16:30:56
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212

[Bug libgcj/13212] AttachCurrentThread() not working

[alessio at itapac dot net]

------- Additional Comments From alessio at itapac dot net  2003-11-27 17:10 -------
I would like to specify that my test case may seem buggy (because I refer to the
thread name jstring allocated by another thread), but it was only done to test
if it was a problem located at the genname call. You can also pass NULL and
forget all the string allocation and the bug will get replicated anyway.
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212

[Bug libgcj/13212] AttachCurrentThread() not working

[alessio at itapac dot net]

------- Additional Comments From alessio at itapac dot net  2003-12-02 09:58 -------
I have investigated deeper. Hope this will help.
The problem is triggered mainly by Java::lang::Thread constructor, which calls
object allocation functions. GC_local_gcj_malloc() blindly gets TSD referred to
memory management (see the line just before the crash reported by GDB), but the
slot for the new created thread has not yet been configured (normally, the
pthread_create() call is wrapped and sets all up, but native threads call the
real pthread_create()). One solution (and hotfix) I have found is to force the
generation of this pool by calling
GC_init_thread_local(GC_new_thread(pthread_self()));
This should be done automatically, but I have never studied nor touched GCC
before, hope only this will help.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212

[Bug libgcj/13212] AttachCurrentThread() not working

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-02-20 16:40 -------
*** Bug 14225 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sturmf at in dot tum dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212

[Bug libgcj/13212] AttachCurrentThread() not working

[greenrd at greenrd dot org]

------- Additional Comments From greenrd at greenrd dot org  2005-06-29 13:21 -------
This breaks rssowl and any other SWT application that uses the embedded Browser
widget.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |greenrd at greenrd dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212

[Bug libgcj/13212] AttachCurrentThread() not working

[greenrd at greenrd dot org]

------- Additional Comments From greenrd at greenrd dot org  2005-07-31 22:21 -------
Strangely, this bug is hard to reproduce - with the rssowl test case - with a
system compiled for i386. However, the rssowl test case (just start rssowl and
load some feeds) appears to be reproducable easily on 64bit x86, according to a
bug report I got from a third party. (I can also reproduce it easily on 32bit
athlon-xp, but not many distros compile for that.) This is the stack trace on 64bit:

#0  0x00002aaaabb794ad in GC_local_malloc_atomic () from
/usr/lib/../lib64/libgcj.so.6
#1  0x00002aaaab7c7554 in _Jv_AllocString () from /usr/lib/../lib64/libgcj.so.6
#2  0x00002aaaab7fcda4 in _Jv_NewString () from /usr/lib/../lib64/libgcj.so.6
#3  0x00002aaaab7fe20d in java::lang::Thread::gen_name () from
/usr/lib/../lib64/libgcj.so.6
#4  0x00002aaaab7fe7d6 in _Jv_AttachCurrentThread () from
/usr/lib/../lib64/libgcj.so.6
#5  0x00002aaaab7c9882 in _Jv_FreeJNIEnv () from /usr/lib/../lib64/libgcj.so.6
#6  0x00002aaab2ad5b32 in callback () from /usr/lib64/libswt-gtk-3138.so
#7  0x00002aaab2ac3bb7 in fn70_4 () from /usr/lib64/libswt-gtk-3138.so
#8  0x00002aaab4b9a5d1 in NSGetModule () from
/usr/lib64/mozilla-1.7.11/components/libnecko.so
#9  0x00002aaab40d9b06 in nsStreamCopierOB::FillOutputBuffer ()
   from /usr/lib64/mozilla-1.7.11/libxpcom.so
#10 0x00002aaab40d8bd5 in nsPipe::OnPipeException () from
/usr/lib64/mozilla-1.7.11/libxpcom.so
#11 0x00002aaab40d9e2d in nsStreamCopierOB::DoCopy () from
/usr/lib64/mozilla-1.7.11/libxpcom.so
#12 0x00002aaab40d9c76 in nsAStreamCopier::Process () from
/usr/lib64/mozilla-1.7.11/libxpcom.so
#13 0x00002aaab40da10f in nsAStreamCopier::HandleContinuationEvent ()
   from /usr/lib64/mozilla-1.7.11/libxpcom.so
#14 0x00002aaab40eeab9 in PL_HandleEvent () from
/usr/lib64/mozilla-1.7.11/libxpcom.so
#15 0x00002aaab4b91d18 in NSGetModule () from
/usr/lib64/mozilla-1.7.11/components/libnecko.so
#16 0x000000377672b8f4 in PR_Select () from /usr/lib/../lib64/libnspr4.so
#17 0x00002aaaac3b698c in start_thread () from /lib64/libpthread.so.0
#18 0x00002aaaac7a116d in clone () from /lib64/libc.so.6
#19 0x0000000000000000 in ?? ()

This comment is just to note that this *is* a showstopper for rssowl on 64-bit
x86 (I assume this backtrace is on opteron, but I don't know - will find out).

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212

[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector

[david at jpackage dot org]

------- Additional Comments From david at jpackage dot org  2005-09-11 02:59 -------
I am experiencing something that looks similar to this with eclipse on x86_64.
Here is the stack trace on amd64.

#0  0x00002aaaabb7c710 in GC_local_gcj_malloc () from /usr/lib/../lib64/libgcj.so.6
#1  0x00002aaaab7c4fa0 in _Jv_AllocObjectNoFinalizer () from
/usr/lib/../lib64/libgcj.so.6
#2  0x00002aaaab7c4ff8 in _Jv_AllocObject () from /usr/lib/../lib64/libgcj.so.6
#3  0x00002aaaab7c50fd in _Jv_remJ () from /usr/lib/../lib64/libgcj.so.6
#4  <signal handler called>
#5  0x00002aaaabb7d835 in GC_local_malloc_atomic () from
/usr/lib/../lib64/libgcj.so.6
#6  0x00002aaaab7c4f13 in _Jv_AllocString () from /usr/lib/../lib64/libgcj.so.6
#7  0x00002aaaab7fcdd4 in _Jv_NewString () from /usr/lib/../lib64/libgcj.so.6
#8  0x00002aaaab7fe3e8 in java::lang::Thread::gen_name () from
/usr/lib/../lib64/libgcj.so.6
#9  0x00002aaaab7fea0d in _Jv_AttachCurrentThread () from
/usr/lib/../lib64/libgcj.so.6
#10 0x00002aaaab7c76c2 in _Jv_FreeJNIEnv () from /usr/lib/../lib64/libgcj.so.6
#11 0x00002aaab17e6b32 in callback () from
/home/david/.eclipse/org.eclipse.osgi/bundles/104/1/.cp/libswt-gtk-3138.so
#12 0x00002aaab17d4bb7 in fn70_4 () from
/home/david/.eclipse/org.eclipse.osgi/bundles/104/1/.cp/libswt-gtk-3138.so
#13 0x00002aaab6f46441 in NSGetModule () from
/usr/lib64/mozilla-firefox-1.0.6/components/libnecko.so
#14 0x00002aaab6342746 in nsStreamCopierOB::FillOutputBuffer () from
/usr/lib64/mozilla-firefox-1.0.6/libxpcom.so
#15 0x00002aaab6341815 in nsPipe::OnPipeException () from
/usr/lib64/mozilla-firefox-1.0.6/libxpcom.so
#16 0x00002aaab6342a6d in nsStreamCopierOB::DoCopy () from
/usr/lib64/mozilla-firefox-1.0.6/libxpcom.so
#17 0x00002aaab63428b6 in nsAStreamCopier::Process () from
/usr/lib64/mozilla-firefox-1.0.6/libxpcom.so
#18 0x00002aaab6342d4f in nsAStreamCopier::HandleContinuationEvent () from
/usr/lib64/mozilla-firefox-1.0.6/libxpcom.so
#19 0x00002aaab63577c9 in PL_HandleEvent () from
/usr/lib64/mozilla-firefox-1.0.6/libxpcom.so
#20 0x00002aaab6f3d3f8 in NSGetModule () from
/usr/lib64/mozilla-firefox-1.0.6/components/libnecko.so
#21 0x00002aaab66e2b14 in PR_Select () from /usr/lib/../lib64/libnspr4.so
#22 0x00002aaaac6ed91c in start_thread () from /lib64/tls/libpthread.so.0
#23 0x00002aaaac5771f2 in clone () from /lib64/tls/libc.so.6
#24 0x0000000000000000 in ?? ()


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212

[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector

[billy dot biggs at gmail dot com]

------- Additional Comments From billy dot biggs at gmail dot com  2005-09-11 03:02 -------
The original bug report is dated 2003-11-27.   greenrd -- are you sure this is
the sasme bug?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |billy dot biggs at gmail dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212

[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector

[greenrd at gcc dot gnu dot org]

------- Additional Comments From greenrd at gcc dot gnu dot org  2005-09-15 00:27 -------
Yes, I'm sure. I know what's going on here.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212