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

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

[stewart at neuron dot com]

------- Comment #10 from stewart at neuron dot com  2005-10-07 13:49 -------
(In reply to comment #9)
> Yes, I'm sure. I know what's going on here.
> 

This is the only bug I was able to find regarding AttachCurrentThread.  I'm
working on getting FUSE-J (Java bindings for FUSE userspace filesystem) working
with GCJ and have run across an apparent bug with
AttachCurrentThread/AttachCurrentThreadAsDaemon whereby the returned JNIEnv has
a corrupted pointer to CallObjectMethod.  I emailed the following to <tromey at
redhat dot com>:

You should be able to setup/reproduce this quickly.  First is to
get/build/install the fuse library:

http://fuse.sourceforge.net/
http://easynews.dl.sourceforge.net/sourceforge/fuse/fuse-2.4.0.tar.gz

./configure --prefix=/usr/local &&
make &&
make install &&
depmod -a &&
modprobe fuse

Second, get fuse-j, the java language bindings

http://www.select-tech.si/fuse/
http://www.select-tech.si/fuse/fuse-j-2.2.3.tar.gz

get and apply my patch for gcj:

http://mrallen.com/misc/fuse-j-2.2.3-gcj.diff

inside fuse-j-2.2.3:

patch -p1 < path_to_patch

then you will need a zip file to test and a mount point. next:

make
sh zipfs_gcj.sh <zip_file> <mount_point>

once it's running, doing a 'df' in another term will crash cause the segfault. 
you will have to have /usr/local/bin in your PATH and execute 'fusermount -u
<mount_point>' to undo the mount. (In reply to comment #9)
> Yes, I'm sure. I know what's going on here.
> 


-- 

stewart at neuron dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stewart at neuron 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

[tromey at gcc dot gnu dot org]

------- Comment #11 from tromey at gcc dot gnu dot org  2005-10-12 18:11 -------
Stewart, can you post attach your backtrace to the PR?
Something like "thread apply all bt" might be useful.
Thanks.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu dot
                   |                            |org


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

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

[stewart at neuron dot com]

------- Comment #12 from stewart at neuron dot com  2005-10-12 20:29 -------
Tom,

This patch from you against gcc-4.0.2 cured the segfault.

Thanks,
Stewart


Index: jni.cc
===================================================================
RCS file: /cvs/gcc/gcc/libjava/jni.cc,v
retrieving revision 1.95.2.2
diff -u -r1.95.2.2 jni.cc
--- jni.cc 6 Sep 2005 16:03:11 -0000 1.95.2.2
+++ jni.cc 12 Oct 2005 18:50:20 -0000
@@ -2341,10 +2341,14 @@
     }

   // Attaching an already-attached thread is a no-op.
-  if (_Jv_GetCurrentJNIEnv () != NULL)
-    return 0;
+  JNIEnv *env = _Jv_GetCurrentJNIEnv ();
+  if (env != NULL)
+    {
+      *penv = reinterpret_cast<void *> (env);
+      return 0;
+    }

-  JNIEnv *env = (JNIEnv *) _Jv_MallocUnchecked (sizeof (JNIEnv));
+  env = (JNIEnv *) _Jv_MallocUnchecked (sizeof (JNIEnv));
   if (env == NULL)
     return JNI_ERR;
   env->p = &_Jv_JNIFunctions;


-- 


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

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

[arno at heho dot snv dot jussieu dot fr]

------- Comment #13 from arno at heho dot snv dot jussieu dot fr  2005-10-22 20:58 -------
Shouldn't part of boehm-gc .h and config files be installed and picked up by   
#include <gcj/cni.h> ?

Especially boehm-gc doc says pthread_create (and some other thread-functions)
should not be called directly, but rather by including gc.h, which redefines
them.
And those redefinitions depend on values from gc_config.h (especially
GC_<arch>_THREADS).


-- 


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

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

[arno at heho dot snv dot jussieu dot fr]

------- Comment #14 from arno at heho dot snv dot jussieu dot fr  2005-10-23 00:21 -------
Created an attachment (id=10046)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10046&action=view)
CC test file


-- 


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

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

[arno at heho dot snv dot jussieu dot fr]

------- Comment #15 from arno at heho dot snv dot jussieu dot fr  2005-10-23 00:22 -------
Created an attachment (id=10047)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10047&action=view)
simple class


-- 


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

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

[arno at heho dot snv dot jussieu dot fr]

------- Comment #16 from arno at heho dot snv dot jussieu dot fr  2005-10-23 00:24 -------
Created an attachment (id=10048)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10048&action=view)
template for using jnew.java and gc-thread-register.cc


-- 


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

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

[arno at heho dot snv dot jussieu dot fr]

------- Comment #17 from arno at heho dot snv dot jussieu dot fr  2005-10-23 00:28 -------
I quickly wrote a testcase to illustrate my point (attached jnew.java Makefile
gc-thread-register.cc) :

Compiling and running gives : 

  ./gc-thread-register 
  Starting first thread ...done
  Collecting from unknown thread.
  Abort trap (core dumped)

  (I know I develop and test on freebsd for which boehm-gc-threading is not
Tier-1, but :)

Compiling and running with FAKE_GC_CONFIG (set correct include path in
Makefile) defined gives :

  ./gc-thread-register 
  Starting first thread ...done
  Starting second thread ...done

NB, this does not necessarily explain (for me) why JvAttachCurrentThread()
fails in some situations (as is the essence of this PR), I just thought that
clearing up the interactions between gcj, boehm-gc and thread-lib might help in
nearing down the causes. 

PS, I thought the attachments where just for this note  


-- 

arno at heho dot snv dot jussieu dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |arno at heho dot snv dot
                   |                            |jussieu dot fr


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]

------- Comment #18 from greenrd at gcc dot gnu dot org  2005-10-23 10:44 -------
Arno - you're missing the point. One of the test cases for this is rssowl (or
more specifically, the SWT Browser widget, which embeds Mozilla on Linux). The
Mozilla embedding subsystems (as opposed to the Mozilla Java plugin system,
which is called OJI) don't know anything about CNI/JNI, so they can't be
expected to create threads using the wrapped call to pthread_create.

In general, AttachCurrentThread must be able to deal with arbitrary threads
created by third-party native code which doesn't know about CNI or JNI. The
current implementation cannot cope with arbitrary threads. See the discussion
on the fedora Java mailing list.


-- 


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

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

[arno at heho dot snv dot jussieu dot fr]

------- Comment #19 from arno at heho dot snv dot jussieu dot fr  2005-10-23 23:37 -------
Subject: Re:  JNI/CNI AttachCurrentThread does not register thread with garbage
collector

Hello,


> Arno - you're missing the point. One of the test cases for this is
> rssowl (or more specifically, the SWT Browser widget, which embeds
> Mozilla on Linux). The Mozilla embedding subsystems (as opposed to
> the Mozilla Java plugin system, which is called OJI) don't know
> anything about CNI/JNI, so they can't be expected to create threads
> using the wrapped call to pthread_create.


> In general, AttachCurrentThread must be able to deal with arbitrary threads
> created by third-party native code which doesn't know about CNI or JNI.

OK, ambitious and interesting design goal, which I really hope we
can achieve. However, for me the original PR just stated "it
doesnt work yet" and providing third-party software an interface to
"register" correctly their threads might be a work-around.
However if the "sine qua non condition" is that third-party code
should work as-is, I agree this is not a solution.

> The current implementation cannot cope with arbitrary threads.

Yop, I thought this is what the original PR was about and what I encounter
as well in daily work (which is why I found the PR).
Why not mark it as "this sometimes can be circumvented by teaching
your code how to register threads to the gcj-jvm; officially not supported,
we are working on a clean solution" (or someting like that).

> See the discussion on the fedora Java mailing list.

Thanx! I was unaware of that discussion. I still think it's ambitious
to nothing impose on third party code (at least for the CNI-part (and
BTW I still think that adding more info to gcj/cni.h is
handy and legitimate and does not interfere which third-party code
as long as recompilation is not an issue)).

Kind regards,


  Arno



-- 


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

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

[aph at gcc dot gnu dot org]

------- Comment #20 from aph at gcc dot gnu dot org  2006-01-09 17:25 -------
This breaks java on s390.

# LD_PRELOAD=/usr/lib/jvm/java-gcj/jre/lib/s390/pr13212.so  /bin/echo 
/bin/echo: symbol lookup error: /usr/lib/libgcj.so.7: undefined symbol:
__data_start

This is because pr13212.so requires libgcj.so.7, and libgcj.so.7 requires
__data_start to be provided by the executable.  /bin/echo does not define
__data_start.

This fixes things on s390:

extern int __data_start __attribute__((weak));
int __data_start;

but it doesn't seem like a good idea in general.  This LD_PRELOAD hack seems to
make every child of /usr/bin/java load libgcj.so.7 and so potentially breaks
all  manner of things.  


-- 

aph at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at redhat 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]

------- Comment #21 from greenrd at gcc dot gnu dot org  2006-01-09 17:32 -------
For those wondering what aph is talking about, the hack he is referring to (or
at least the initial proposal for it) is at
https://www.redhat.com/archives/fedora-devel-java-list/2006-January/msg00002.html


-- 


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

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

[jakub at gcc dot gnu dot org]

------- Comment #22 from jakub at gcc dot gnu dot org  2006-01-09 17:41 -------
Just FYI, dlsym (RTLD_NEXT, "pthread_create") is wrong when using glibc.
pthread_create is symbol versioned and there are on most arches 2 different
pthread_create implementations.  By using dlsym (RTLD_NEXT, "pthread_create")
you will use the glibc 2.0 compatible one, which will have seriously bad
side-effects.  On x86_64 you are lucky because it has just the newer version.


-- 


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

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

[jakub at gcc dot gnu dot org]

------- Comment #23 from jakub at gcc dot gnu dot org  2006-01-09 17:42 -------
Forgot to mention, the fix would be to use dlvsym (RTLD_NEXT, "pthread_create",
"GLIBC_2.1") (on i?86 and several other platforms) and different versions
on other arches (GLIBC_2.2.5 on x86_64, etc.).


-- 


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

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

[cagney at redhat dot com]

------- Comment #24 from cagney at redhat dot com  2006-01-09 18:21 -------
(In reply to comment #20)

> but it doesn't seem like a good idea in general.  This LD_PRELOAD hack seems to
> make every child of /usr/bin/java load libgcj.so.7 and so potentially breaks
> all  manner of things.  
> 

s/seems to make/always makes/ :-) Sub-processes inherit that environmnent
variable and so will always attempt the pre-load.  Been there, rat hole.


-- 


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

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

[tromey at gcc dot gnu dot org]

------- Comment #25 from tromey at gcc dot gnu dot org  2006-01-13 22:44 -------
We could remove the LD_PRELOAD entry during libgcj startup.
Would that work?

I am concerned about comment #23 though -- we can get a list of
all the version numbers we need, I suppose, but it seems awfully
fragile.  It may suffice for FC5 though.  (Jakub -- is there an
easy way to get this list?  Do you have it?)


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #26 from rguenth at gcc dot gnu dot org  2006-03-24 14:08 -------
Note that with the "fix" installed on the 4.1 branch programs linked against
libgcj.so get to use libgcjs pthread_create wrapper, but programs later opening
libgcj.so via dlopen, like OpenOffice, fail here.  LD_PRELOADing libgcj.so
from the 4.1 branch will not help either, because libgcj.so does not provide
the correct versioned symbol.  Fixing that reveals maybe another problem for
OpenOffice, namely we now crash like

Program received signal SIGSEGV, Segmentation fault.
0xb78bb7f3 in GC_is_black_listed () from /usr/lib/libgcj.so.7.0.0
(gdb) bt
#0  0xb78bb7f3 in GC_is_black_listed () from /usr/lib/libgcj.so.7.0.0
#1  0xb78b979d in GC_allochblk_nth () from /usr/lib/libgcj.so.7.0.0
#2  0xb78b9b62 in GC_allochblk () from /usr/lib/libgcj.so.7.0.0
#3  0xb78c527d in GC_new_hblk () from /usr/lib/libgcj.so.7.0.0
#4  0xb78bb581 in GC_allocobj () from /usr/lib/libgcj.so.7.0.0
#5  0xb78c00a8 in GC_generic_malloc_inner () from /usr/lib/libgcj.so.7.0.0
#6  0xb78c0511 in GC_generic_malloc_inner_ignore_off_page ()
   from /usr/lib/libgcj.so.7.0.0
#7  0xb78be3f7 in GC_grow_table () from /usr/lib/libgcj.so.7.0.0
#8  0xb78be61a in GC_register_finalizer_inner () from /usr/lib/libgcj.so.7.0.0
#9  0xb78be7c3 in GC_register_finalizer_no_order ()
   from /usr/lib/libgcj.so.7.0.0
#10 0xb72d9b2d in _Jv_RegisterFinalizer () from /usr/lib/libgcj.so.7.0.0
#11 0xb72d2052 in _Jv_NewStringUtf8Const () from /usr/lib/libgcj.so.7.0.0
#12 0xb72a5deb in _Jv_Linker::ensure_class_linked ()
   from /usr/lib/libgcj.so.7.0.0
#13 0xb72a5fbe in _Jv_Linker::wait_for_state () from /usr/lib/libgcj.so.7.0.0
#14 0xb72cc421 in java::lang::Class::initializeClass ()
   from /usr/lib/libgcj.so.7.0.0
#15 0xb72cc3c3 in java::lang::Class::initializeClass ()
   from /usr/lib/libgcj.so.7.0.0
#16 0xb7297417 in _Jv_CreateJavaVM () from /usr/lib/libgcj.so.7.0.0
#17 0xb729c58d in JNI_CreateJavaVM () from /usr/lib/libgcj.so.7.0.0
#18 0xacbf47fc in jfw_plugin_startJavaVirtualMachine ()
   from /usr/lib/ooo-2.0/program/sunjavaplugin.so
#19 0xb57df25e in jfw_startVM () from /usr/lib/ooo-2.0/program/libjvmfwk.so.3

See https://bugzilla.novell.com/show_bug.cgi?id=153386 - open the attached "A
sample .odb file" and click on 'Tables' on i686.


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #27 from rguenth at gcc dot gnu dot org  2006-03-24 15:35 -------
Created an attachment (id=11115)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11115&action=view)
patch fixing OO problems with LD_PRELOAD of libgcj

One problem with LD_PRELOADing of libgcj.so is that boehm starts with
GC_all_interior_pointers == 1 and libgcj sets it to 0 after startup, so we
segfault because in GC_bl_init we did not properly initialize GC_old_normal_bl.

Changing the boehm default config and exporting pthread_create with the glibc
versioning makes OO work with LD_PRELOADing of libgcj.so.  This is what the
patch does.


-- 


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

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

[aph at gcc dot gnu dot org]

------- Comment #28 from aph at gcc dot gnu dot org  2006-03-24 17:41 -------
Richard Guenther: should this be posted to java@gcc.gnu.org for discussion?


-- 


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

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

[matz at suse dot de]

------- Comment #29 from matz at suse dot de  2006-03-25 01:07 -------
There is a minor glitch in the patch from Richard, which went in when
cleaning it up.  This line:

+ __asm__ (".symver pthread_create, pthread_create@@" GC_PTHREAD_SYM_VERSION);

which creates the right version of the overriding symbol actually needs
to read

+ __asm__ (".symver GC_pthread_create,pthread_create@@"GC_PTHREAD_SYM_VERSION);

as that is how the function now is called.  regtesting of libjava with
that change in the patch on x86_64 looks good now (it doesn't with the
patch as posted).


-- 

matz at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matz at suse dot de


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

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

[mckinlay at redhat dot com]

------- Comment #30 from mckinlay at redhat dot com  2006-03-30 07:00 -------
Created an attachment (id=11161)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11161&action=view)
patch implementing GC_register_my_thread

Here's a patch that fixes this by adding functions to the GC that allow thread
registration directly from JNI_AttachCurrentThread. Aside from being fragile,
solutions that rely on intercepting pthread_create are problematic because the
GC will attempt to suspend other non-Java threads (see rh bug 180637 for an
example)

This patch has been tested sucessfully with openoffice.org.


-- 

mckinlay at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |mckinlay at redhat dot com
                   |dot org                     |
             Status|NEW                         |ASSIGNED


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #31 from rguenth at gcc dot gnu dot org  2006-03-30 15:48 -------
How did you test the patch with OpenOffice?  Are there OpenOffice modifications
necessary?


-- 


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

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

[mckinlay at redhat dot com]

------- Comment #32 from mckinlay at redhat dot com  2006-03-30 15:51 -------
(In reply to comment #31)

Yes, this patch should fix all the OpenOffice issues.


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #33 from rguenth at gcc dot gnu dot org  2006-05-22 16:16 -------
What's the status with this patch?


-- 


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

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

[arno at heho dot snv dot jussieu dot fr]

------- Comment #34 from arno at heho dot snv dot jussieu dot fr  2006-06-10 18:00 -------
(In reply to comment #30)

This patch works great for me.
Tested on i386-freebsd6 and i386-linux-2.6.15-gentoo by calling CNI in threads
created by an absolute non-CNI aware c++ Corba library.


-- 


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

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

[davidf at sjsoft dot com]

------- Comment #35 from davidf at sjsoft dot com  2006-07-14 14:02 -------
This is also an issue with PyLucene under mod_python (in Apache).
PyLucene compiles Lucene with gcj and then wraps the interface to be callable
from Python. In order to do this it currently needs to create any Python
threads as wrappers of gcj-initialized threads. However under Apache the
threads are simply native threads that are attached to, so that doesn't work.
I hope the current patch will remedy this situation.


-- 

davidf at sjsoft dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davidf at sjsoft 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

[tromey at gcc dot gnu dot org]

------- Comment #36 from tromey at gcc dot gnu dot org  2006-08-21 22:07 -------
Subject: Bug 13212

Author: tromey
Date: Mon Aug 21 22:07:30 2006
New Revision: 116313

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116313
Log:
boehm-gc
        PR libgcj/13212:
        * configure.ac: Check for pthread_getattr_np(). Remove
        GC_PTHREAD_SYM_VERSION detection.
        * include/gc.h (GC_register_my_thread, GC_unregister_my_thread,
        GC_get_thread_stack_base): New declarations.
        * pthread_support.c (GC_register_my_thread, GC_unregister_my_thread,
        GC_get_thread_stack_base): New functions.
        (GC_delete_thread): Don't try to free the first_thread.
        * misc.c (GC_init_inner): Use GC_get_thread_stack_base() if possible.
        (pthread_create_, constr): Removed.
        (pthread_create): Don't rename.
        * include/gc_ext_config.h.in: Rebuilt.
        * include/gc_pthread_redirects.h (pthread_create): Define 
        unconditionally.
        * include/gc_config.h.in: Rebuilt.
        * configure: Rebuilt.
libjava
        * java/lang/natThread.cc (_Jv_AttachCurrentThread): Attach thread
        to GC.
        (_Jv_DetachCurrentThread): Detach thread from GC.
        * include/boehm-gc.h (_Jv_GCAttachThread, _Jv_GCDetachThread):
        Declare.
        * boehm.cc (_Jv_GCAttachThread): New function.
        (_Jv_GCDetachThread): Likewise.

Modified:
    trunk/boehm-gc/ChangeLog
    trunk/boehm-gc/configure
    trunk/boehm-gc/configure.ac
    trunk/boehm-gc/include/gc.h
    trunk/boehm-gc/include/gc_config.h.in
    trunk/boehm-gc/include/gc_ext_config.h.in
    trunk/boehm-gc/include/gc_pthread_redirects.h
    trunk/boehm-gc/misc.c
    trunk/boehm-gc/pthread_support.c
    trunk/libjava/ChangeLog
    trunk/libjava/boehm.cc
    trunk/libjava/include/boehm-gc.h
    trunk/libjava/java/lang/natThread.cc


-- 


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

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

[tromey at gcc dot gnu dot org]

------- Comment #37 from tromey at gcc dot gnu dot org  2006-08-21 22:09 -------
I've checked in the patch which enables explicit thread registration.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.2.0


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

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

[tromey at gcc dot gnu dot org]

------- Comment #38 from tromey at gcc dot gnu dot org  2006-09-01 16:16 -------
Subject: Bug 13212

Author: tromey
Date: Fri Sep  1 16:16:15 2006
New Revision: 116631

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116631
Log:
        PR libgcj/28698:
        * libgcj_bc.c (DECLARE_PRIM_TYPE): New macro.  Declare primitive
        classes.

boehm-gc
        PR libgcj/13212:
        * configure.ac: Check for pthread_getattr_np(). Remove
        GC_PTHREAD_SYM_VERSION detection.
        * include/gc.h (GC_register_my_thread, GC_unregister_my_thread,
        GC_get_thread_stack_base): New declarations.
        * pthread_support.c (GC_register_my_thread, GC_unregister_my_thread,
        GC_get_thread_stack_base): New functions.
        (GC_delete_thread): Don't try to free the first_thread.
        * misc.c (GC_init_inner): Use GC_get_thread_stack_base() if possible.
        (pthread_create_, constr): Removed.
        (pthread_create): Don't rename.
        * include/gc_ext_config.h.in: Rebuilt.
        * include/gc_pthread_redirects.h (pthread_create): Define
        unconditionally.
        * include/gc_config.h.in: Rebuilt.
        * configure: Rebuilt.
libjava
        * java/lang/natThread.cc (_Jv_AttachCurrentThread): Attach thread
        to GC.
        (_Jv_DetachCurrentThread): Detach thread from GC.
        * include/boehm-gc.h (_Jv_GCAttachThread, _Jv_GCDetachThread):
        Declare.
        * boehm.cc (_Jv_GCAttachThread): New function.
        (_Jv_GCDetachThread): Likewise.

gcc/java/ChangeLog
        * jvspec.c (lang_specific_driver): Add -s-bc-abi when needed.
libjava/ChangeLog
        * configure, Makefile.in: Rebuilt.
        * Makefile.am (toolexeclib_LTLIBRARIES): Add libgcj_bc.la.
        (libgcj_bc_la_SOURCES): New variable.
        (libgcj_bc_la_LDFLAGS): Likewise.
        (libgcj_bc_la_LIBADD): Likewise.
        (libgcj_bc_la_DEPENDENCIES): Likewise.
        (libgcj_bc_la_LINK): Likewise.
        (libgcj_bc_dummy_LINK): Likewise.
        (libgcj_bc.la): New target.
        (install-exec-hook): Likewise.
        * libgcj.spec.in (*lib): Use LIBGCJ_SPEC.
        * libgcj_bc.c: New file.
        * configure.ac (LIBGCJ_SPEC): New subst.
        * configure.host (use_libgcj_bc): New variable.

Added:
    branches/gcj-eclipse/libjava/libgcj_bc.c
      - copied, changed from r116204, trunk/libjava/libgcj_bc.c
Modified:
    branches/gcj-eclipse/boehm-gc/ChangeLog
    branches/gcj-eclipse/boehm-gc/configure
    branches/gcj-eclipse/boehm-gc/configure.ac
    branches/gcj-eclipse/boehm-gc/dyn_load.c
    branches/gcj-eclipse/boehm-gc/include/gc.h
    branches/gcj-eclipse/boehm-gc/include/gc_config.h.in
    branches/gcj-eclipse/boehm-gc/include/gc_ext_config.h.in
    branches/gcj-eclipse/boehm-gc/include/gc_pthread_redirects.h
    branches/gcj-eclipse/boehm-gc/include/private/pthread_support.h
    branches/gcj-eclipse/boehm-gc/misc.c
    branches/gcj-eclipse/boehm-gc/os_dep.c
    branches/gcj-eclipse/boehm-gc/pthread_stop_world.c
    branches/gcj-eclipse/boehm-gc/pthread_support.c
    branches/gcj-eclipse/gcc/java/ChangeLog
    branches/gcj-eclipse/gcc/java/jvspec.c
    branches/gcj-eclipse/libjava/ChangeLog
    branches/gcj-eclipse/libjava/Makefile.am
    branches/gcj-eclipse/libjava/Makefile.in
    branches/gcj-eclipse/libjava/boehm.cc
    branches/gcj-eclipse/libjava/configure
    branches/gcj-eclipse/libjava/configure.ac
    branches/gcj-eclipse/libjava/configure.host
    branches/gcj-eclipse/libjava/gcj/Makefile.in
    branches/gcj-eclipse/libjava/include/Makefile.in
    branches/gcj-eclipse/libjava/include/boehm-gc.h
    branches/gcj-eclipse/libjava/java/lang/natThread.cc
    branches/gcj-eclipse/libjava/libgcj.spec.in
    branches/gcj-eclipse/libjava/testsuite/Makefile.in


-- 


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

[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

[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