This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: GC seems to kill process



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..



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]