GC seems to kill process

[Andi Vajda]

On Wed, 22 Mar 2006, Boehm, Hans wrote:

> Does the system log say anything more useful?
>
> This often means that a SIGSEGV was generated while SIGSEGV was blocked.
> A semi-friendly kernel would at least put the PC value in the system
> log, which might give us some chance at determining what's happening,
> possibly by setting a breakpoint in a debugger just before this happens.

I couldn't find anything in the system log but I did a little more digging and 
found that:

   - the simple java program below works fine:

public class foo {
     static public void main(String[] args)
     {
         System.err.println("before");
         System.gc();
         System.err.println("after");
     }
}


   - the simple c++ program below works fine too:

#include <stdio.h>
#include <gcj/cni.h>
#include <java/lang/System.h>
#include <java/io/PrintStream.h>

int main(int argc, char **argv)
{
   printf("before cni\n");
   JvCreateJavaVM(NULL);
   JvAttachCurrentThread(NULL, NULL);

   java::lang::System::err->println(JvNewStringUTF("before"));
   java::lang::System::gc();
   java::lang::System::err->println(JvNewStringUTF("after"));
   printf("after cni\n");
}


So, I've been able to reproduce this only within python. I rebuilt python with 
gcc 4.1.0 but that didn't make a difference. I then ran the same thing in gdb 
and got this:

Starting program: /usr/local/bin/python
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 16079)]
Python 2.4.2 (#1, Mar 22 2006, 10:28:40)
[GCC 4.1.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import PyLucene
[New Thread 32769 (LWP 16082)]
[New Thread 16386 (LWP 16083)]
>>> PyLucene.System.gc()
>>>
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16386 (LWP 16083)]
GC_local_malloc_atomic (bytes=58)
     at ../../../gcc-4.1.0/boehm-gc/pthread_support.c:331
331             ptr_t my_entry = *my_fl;
(gdb) bt
#0  GC_local_malloc_atomic (bytes=58)
     at ../../../gcc-4.1.0/boehm-gc/pthread_support.c:331
#1  0xb659b632 in _Jv_AllocString (len=19) at java-gc.h:57
#2  0xb65d6842 in _Jv_NewStringLatin1 (bytes=0xb7e629ba "Bad file descriptor",
     len=19) at cni.h:42
#3  0xb65ce039 in gnu::java::nio::channels::FileChannelImpl::implCloseChannel 
(
     this=0x168ac8) at cni.h:60
#4  0xb682bbc9 in java.nio.channels.spi.AbstractInterruptibleChannel.close() (
     this=0x168ac8) at AbstractInterruptibleChannel.java:79
#5  0xb6655f7e in gnu.java.nio.channels.FileChannelImpl.finalize() (
     this=0x168ac8) at FileChannelImpl.java:158
#6  0xb65d3d3d in _Jv_FinalizeObject (obj=0x168ac8)
     at ../../../gcc-4.1.0/libjava/java/lang/natObject.cc:121
#7  0xb65de5ee in call_finalizer (obj=0x168ac8, client_data=0xb65d3d20)
     at ../../../gcc-4.1.0/libjava/boehm.cc:527
#8  0xb6bd2812 in GC_invoke_finalizers ()
     at ../../../gcc-4.1.0/boehm-gc/finalize.c:787
#9  0xb65de9b4 in _Jv_RunFinalizers ()
     at ../../../gcc-4.1.0/libjava/boehm.cc:540
#10 0xb65c8cd3 in gnu::gcj::runtime::FinalizerThread::run (this=0xdc640)
     at ../../../gcc-4.1.0/libjava/gnu/gcj/runtime/natFinalizerThread.cc:60
#11 0xb65d883b in _Jv_ThreadRun (thread=0xdc640)
     at ../../../gcc-4.1.0/libjava/java/lang/natThread.cc:297
#12 0xb65e0060 in really_start (x=0x14aff8)
     at ../../../gcc-4.1.0/libjava/posix-threads.cc:432
#13 0xb7f9318e in pthread_start_thread () from /lib/libpthread.so.0
#14 0xb7f93334 in pthread_start_thread_event () from /lib/libpthread.so.0
#15 0xb7e146ea in clone () from /lib/libc.so.6
(gdb)

the my_fl variable seems bogus indeed:

(gdb) p my_fl
$1 = (ptr_t *) 0x40
(gdb)


Andi..