GC failure w/ THREAD_LOCAL_ALLOC ?

Loren James Rittle rittle@latour.rsch.comm.mot.com
Wed Mar 20 19:32:00 GMT 2002


>On Wed, 20 Mar 2002, Bryce McKinlay wrote:
>> It runs fine without THREAD_LOCAL_ALLOC.

> You're having better luck than I am, then.  I did get random, infrequent
> crashes in my application.  But without THREAD_LOCAL_ALLOC I don't get
> that far:

> 0x40c45363 in GC_mark_from (mark_stack_top=0x805b0e8,
> mark_stack=0x805b000,
>    mark_stack_limit=0x8063000) at ../../../boehm-gc/mark.c:654
> 654               deferred = *limit;

Based on my experience porting threaded boehm-gc to i386-*-freebsd*
(thanks really to Hans for further generalizing thread support before
my final required tweaks went in), I have developed unposted patches
required to get threaded boehm-gc on alpha*-*-freebsd* working (at
least I thought they would).  Neither port uses THREAD_LOCAL_ALLOC to
my knowledge.  i386-*-freebsd* is working.  The new alpha port is not.

Two days ago, I saw this exact crash point on alpha*-*-freebsd* using
a blend of configuration from i386-*-freebsd* (for per-OS stuff) and
other supported alpha targets (for per-CPU stuff).  I hadn't reported
it yet since I thought it was something boneheaded I had done... ;-)
...and I hadn't found time to fully debug it yet.  I still haven't
debugged it yet but I feel better about reporting it now.

> (gdb) p limit
> $1 = (word *) 0x86e90c4

If memory serves me, ``p limit'' printed an address as you see.
``p *limit'' failed since no memory was actually mapped at that point
(i.e. why it SEGV upon *limit).

> the address isn't mapped:
>
> (gdb) call GC_print_heap_sects()
> Total heap size: 5672960
> Section 0 from 0x806b000 to 0x807b000 2/16 blacklisted
[...]
>
> (gdb) p GC_greatest_plausible_heap_addr
> $2 = 0xaed9000



More information about the Java mailing list