no stacktrace available

Bart Locanthi bart@sabl.com
Tue Dec 14 22:06:00 GMT 2004


i thought one of the big changes w/ netbsd 2.0 was native threads.

perhaps the netbsd binary package for gcj isn't configured to use them? 
what's your guess as to the right thing to say to configure?

Boehm, Hans wrote:

>I believe the GC currently has not thread support under NetBSD,
>at least not in my version.  The symptom below is typical for an
>attempt to run the single-threaded GC in a multi-threaded
>environment.
>
>If your application doesn't need threads (and uses at most trivial
>finalizers), you might be able to get gcj up without thread
>support.
>
>Jerome Laban posted about an attempt to fix the GC (July 9,
>http://news.gmane.org/gmane.comp.programming.garbage-collection.boehmgc)
>but I don't believe that resulted in a final patch.  I think he
>ended up trying to fix real-time signals, which the collector
>uses on some platforms for stopping threads, but are not essential for
>the GC.  (They're not currently used on Linux.)
>
>I don't know what the status of his work is.  Nor do I understand why
>the Linux code doesn't just work.  But I haven't personally tried
>to get the collector up on NetBSD.
>
>Hans
>
>  
>
>>-----Original Message-----
>>From: java-owner@gcc.gnu.org 
>>[mailto:java-owner@gcc.gnu.org]On Behalf Of
>>Michael Koch
>>Sent: Tuesday, December 14, 2004 5:51 AM
>>To: Bart Locanthi
>>Cc: java@gcc.gnu.org
>>Subject: Re: no stacktrace available
>>
>>
>>Am Dienstag, 14. Dezember 2004 14:43 schrieb Bart Locanthi:
>>    
>>
>>>oops, i spoke too soon. got a core dump that may again be related
>>>to threading/gc. i vaguely remember the form of the error - an
>>>infinite stack trace.
>>>
>>>...
>>>#494 0x485f01b0 in GC_clear_stack_inner () from
>>>/usr/pkg/gcc3/lib/libgcj.so.4
>>>#495 0x485f01b0 in GC_clear_stack_inner () from
>>>/usr/pkg/gcc3/lib/libgcj.so.4
>>>#496 0x485f01b0 in GC_clear_stack_inner () from
>>>/usr/pkg/gcc3/lib/libgcj.so.4
>>>#497 0x485f01b0 in GC_clear_stack_inner () from
>>>/usr/pkg/gcc3/lib/libgcj.so.4
>>>#498 0x485f01b0 in GC_clear_stack_inner () from
>>>/usr/pkg/gcc3/lib/libgcj.so.4
>>>#499 0x485f01b0 in GC_clear_stack_inner () from
>>>/usr/pkg/gcc3/lib/libgcj.so.4
>>>#500 0x485f01b0 in GC_clear_stack_inner () from
>>>/usr/pkg/gcc3/lib/libgcj.so.4
>>>#501 0x485f01b0 in GC_clear_stack_inner () from
>>>/usr/pkg/gcc3/lib/libgcj.so.4
>>>#502 0x485f01b0 in GC_clear_stack_inner () from
>>>/usr/pkg/gcc3/lib/libgcj.so.4
>>>#503 0x485f01b0 in GC_clear_stack_inner () from
>>>/usr/pkg/gcc3/lib/libgcj.so.4
>>>#504 0x485f01b0 in GC_clear_stack_inner () from
>>>/usr/pkg/gcc3/lib/libgcj.so.4
>>>#505 0x485f01b0 in GC_clear_stack_inner () from
>>>/usr/pkg/gcc3/lib/libgcj.so.4
>>>      
>>>
>>For this I can only say: Try newest GCJ from CVS and see if its still 
>>not fixed.
>>
>>
>>Michael
>>-- 
>>Homepage: http://www.worldforge.org/
>>
>>    
>>



More information about the Java mailing list