This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: "hello, world" fails on FreeBSD with shared libraries: gc issue?
- To: "'Jan Mikkelsen'" <janm at transactionware dot com>, java at gcc dot gnu dot org
- Subject: RE: "hello, world" fails on FreeBSD with shared libraries: gc issue?
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- Date: Wed, 10 Oct 2001 16:57:39 -0700
Unfortunately, I'm not a FreeBSD expert, and I don't have access to a
FreeBSD machine.
Are you building with Posix thread support? My impression is that there is
currently no known 100% stable port of the GC to FreeBSD threads. I've been
getting patches from Loren James Rittle, some of which are in my 6.1alpha1
version of the GC, but haven't been checked into the gcc tree. I have some
more that are about to go in. But the author's experience was that the
result was still not 100% stable. It's unknown whether that's due to GC or
thread library problems (which might already have been fixed in later
releases).
That having been said, the next thing to check here is to verify that the
collector sees all of the relevant static variables, especially if it only
fails with shared libraries. Call the C function GC_dump() sometime shortly
before it fails. Make sure that the addresses of variables like fo_head are
included in one of the address ranges that are treated as roots.
Looking at this more closely, I suspect a likely problem is that the gcj
version of the collector doesn't have DYNAMIC_LOADING turned on (in
gcconfig.h) for FreeBSD. You might try doing that and taking the supporting
dyn_load.c code from 6.1alpha1 (or another FreeBSD-patched version of the
collector).
Hans
> -----Original Message-----
> From: Jan Mikkelsen [mailto:janm@transactionware.com]
> Sent: Wednesday, October 10, 2001 1:24 PM
> To: java@gcc.gnu.org
> Subject: "hello, world" fails on FreeBSD with shared libraries: gc
> issue?
>
>
> I'm seeing a problem when compiling "hello, world" with
> shared libraries on
> FreeBSD 4.4. Stack trace below.
>
> Ignore the comments from my earlier message about a problem in
> lang/java/finalizer.c; they happened after I tried merging
> some changes
> from the FreeBSD boehm-gc port into boehm-gc/os_dep.c.
>
> Any ideas on where to go from here?
>
> Core was generated by `a.out'.
> Program terminated with signal 10, Bus error.
> Reading symbols from /pkgs/gcc-20011007/lib/libgcj.so.2...done.
> Reading symbols from /usr/lib/libm.so.2...done.
> Reading symbols from /pkgs/gcc-20011007/lib/libgcjgc.so.1...done.
> Reading symbols from /pkgs/gcc-20011007/lib/libzgcj.so.0...done.
> Reading symbols from /usr/lib/libc.so.4...done.
> Reading symbols from /usr/libexec/ld-elf.so.1...done.
> #0 0x28441e83 in GC_grow_table (table=0x2844c804,
> log_size_ptr=0x2844c80c)
> at ../../../gcc-20011007/boehm-gc/finalize.c:130
> 130 p -> next = new_table[new_hash];
> (gdb) where
> #0 0x28441e83 in GC_grow_table (table=0x2844c804,
> log_size_ptr=0x2844c80c)
> at ../../../gcc-20011007/boehm-gc/finalize.c:130
> #1 0x28442221 in GC_register_finalizer_inner (obj=0x8073fb0,
> fn=0x28191294 <call_finalizer>, cd=0x281fb7f4, ofn=0x0, ocd=0x0,
> mp=0x284421d0 <GC_null_finalize_mark_proc>)
> at ../../../gcc-20011007/boehm-gc/finalize.c:339
> #2 0x2844245e in GC_register_finalizer_no_order (obj=0x8073fb0,
> fn=0x28191294 <call_finalizer>, cd=0x281fb7f4, ofn=0x0, ocd=0x0)
> at ../../../gcc-20011007/boehm-gc/finalize.c:491
> #3 0x281912d2 in _Jv_RegisterFinalizer(void*, void
> (*)(java::lang::Object*)) (
> object=0x8073fb0, meth=0x281fb7f4 <unintern>)
> at ../../../gcc-20011007/libjava/boehm.cc:397
> #4 0x281fbb33 in _Jv_NewStringUtf8Const(_Jv_Utf8Const*)
> (str=0x281fb7f4)
> at ../../../gcc-20011007/libjava/java/lang/natString.cc:293
> #5 0x281f8e09 in _Jv_PrepareCompiledClass(java::lang::Class*)
> (klass=0x28346720)
> at ../../../gcc-20011007/libjava/java/lang/natClassLoader.cc:261
> #6 0x281f78e9 in java::lang::Class::initializeClass()
> (this=0x28346720)
> at ../../../gcc-20011007/libjava/java/lang/natClass.cc:703
> #7 0x282866bd in _Jv_InitClass (klass=0x281fb7f4)
> at ../../../gcc-20011007/libjava/java/lang/Class.h:256
> internal error - unimplemented function
> unk_lang_create_fundamental_type
> called.
>
>
> Thanks,
>
> Jan Mikkelsen
>