GC failure w/ THREAD_LOCAL_ALLOC ?
Loren James Rittle
rittle@latour.rsch.comm.mot.com
Wed Mar 20 19:32:00 GMT 2002
>On 2002年3月20日, 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