[Gc] Segfault in GC_mark_from in libgc 7.1 (released tarball)

Boehm, Hans hans.boehm at hp.com
Mon Aug 18 13:18:51 PDT 2008



> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Klaus Treichel
> Sent: Sunday, August 17, 2008 4:23 AM
> To: Bruce Hoult
> Cc: gc at napali.hpl.hp.com
> Subject: Re: [Gc] Segfault in GC_mark_from in libgc 7.1
> (released tarball)
>
> Am Mittwoch, den 13.08.2008, 09:39 +0200 schrieb Klaus Treichel:
> > Am Mittwoch, den 13.08.2008, 10:17 +1200 schrieb Bruce Hoult:
> > > 2008/8/13 Klaus Treichel <ktreichel at web.de>:
> > > > Hi,
> > > >
> > > > what i found out until now is:
> > > >
> > > > 1. limit is an inaccessible address
> > > > (gdb) print limit
> > > > $26 = 0xb55010 <Address 0xb55010 out of bounds>
> > > >
> > > > where 0xb54fff is accessible.
> > > >
> > > > 2. limit is in the range between least_ha and
> greatest_ha so the
> > > > check doesn't prevent the segfault.
That check should never be needed to prevent a segfault.  GC_least_plausible_heap_addr and GC_greatest_plausible_heap_addr are used to:

a) Eliminate obviously implausible "candidate pointers" and hence speed up pointer validation.
b) Detect "near misses" in support of the blacklisting code.

It would be interesting to know what GC_find_header(0xb54fff) is.  Does it think this block is in the heap?  Or is this ostensibly part of the root set.  If it's non-null. i.e. if the block is in the heap, what's *GC_find_header(0xb54fff)?

> > >
> > > Are least_ha and greatest_ha both accessible?
> > >
> > > If so then I guess the OS has given the GC two chunks of
> memory (in
> > > a heap expansion) with an inaccessible region in between.
>  I think
> > > that would violate an assumption in the marking code.
> >
> > least_ha == GC_least_plausible_heap_addr == 0x7acff8 here is
> > accessible
> >
> > greatest_ha == GC_greatest_plausible_heap_addr == 0x2b9dde8 is not
> > accessible
That's fine.  I'll check in an addition to the declaration comment in gc_mark.h to make that clearer.

>
> It looks like GC_greatest_plausible_heap_addr is set to the
> inaccessible memory location in alloc.c line 941.
>
> Setting expansion_slop to 0 fixed my segfault but i'm not
> sure how this affects overall GC performance.
I'm not sure I understand why that helps. Coincidence?

>
> One question came up by looking at the code (line 939 in alloc.c):
>
>         word new_limit = (word)space + bytes + expansion_slop;
>         if (new_limit > (word)space) {
>
> new_limit should be greater than space except adding
> expansion_slop causes an overflow.
See the comment above that and GC_add_to_heap.  This should be fine.

Hans

>
> In this case GC_greatest_plausible_heap_addr is not updated
> that might cause allocated memory not being scanned.
>
> Klaus
>
>
>



More information about the Gc mailing list