[Gc] GC_malloc bug?

Boehm, Hans hans.boehm at hp.com
Tue Dec 7 15:06:13 PST 2004


It looks like you are getting lots of false pointers into one particular
region.  This effect is then getting compounded by the large
GC_free_space_divisor setting and an accounting bug in the GC.

The interesting lines in the GC_dump output are

Section 31 from 0x9e03000 to 0x9eff000 0/252 blacklisted
Section 32 from 0x9f31000 to 0xa04c000 1/283 blacklisted
Section 33 from 0x1851f000 to 0x1865d000 291/318 blacklisted
Section 34 from 0x1866d000 to 0x187d3000 320/358 blacklisted

The last two lines give regions which are almost entirely
blacklisted, which is bad.

To track down the cause of the false pointers, you can try building
the GC with -DPRINT_BLACK_LIST.

The following patch should fix the accounting bug, which should
make this problem disappear in this case, and much less likely in
general.  (It's already quite unlikely.) For gc7.0, I got rid of
the equivalent of GC_words_wasted completely, which should really
make this failure completely impossible.  For 6.3/6.4 that's not
easily possible, and I've instead included a hack to
GC_adj_words_allocd, which should have the same effect, by
considering GC_words_wasted only if it is within reason.

This has not been thoroughly tested, but is now in my 6.4 tree.

Hans

[hboehm at hoh ~/gc_master]$ diff -u allchblk.c.orig allchblk.c
--- allchblk.c.orig     2004-12-07 14:17:37.000000000 -0800
+++ allchblk.c  2004-12-07 14:59:42.000000000 -0800
@@ -692,7 +692,7 @@
                      struct hblk * h;
                      struct hblk * prev = hhdr -> hb_prev;

-                     GC_words_wasted += total_size;
+                     GC_words_wasted += BYTES_TO_WORDS(total_size);
                      GC_large_free_bytes -= total_size;
                      GC_remove_from_fl(hhdr, n);
                      for (h = hbp; h < limit; h++) {

diff alloc.c.orig alloc.c -u
--- alloc.c.orig        2004-06-05 22:53:14.000000000 -0700
+++ alloc.c     2004-12-07 14:59:49.688258797 -0800
@@ -198,7 +196,8 @@
        /* had been reallocated this round. Finalization is user        */
        /* visible progress.  And if we don't count this, we have       */
        /* stability problems for programs that finalize all objects.   */
-    result += GC_words_wasted;
+    if ((GC_words_wasted >> 2) < result)
+        result += GC_words_wasted;
        /* This doesn't reflect useful work.  But if there is lots of   */
        /* new fragmentation, the same is probably true of the heap,    */
        /* and the collection will be correspondingly cheaper.          */

> -----Original Message-----
> From: Kees Cook [mailto:kees at outflux.net]
> Sent: Tuesday, December 07, 2004 1:23 PM
> To: Boehm, Hans
> Subject: Re: [Gc] GC_malloc bug?
> 
> 
> On Tue, Dec 07, 2004 at 01:06:06PM -0800, Boehm, Hans wrote:
> > If you mail it to me, I'll summarize my conclusions.  It might be
> > best to just send the last MB or so.
> 
> it bzip'd nicely... attached.
> 
> 
> -- 
> Kees Cook                                            @outflux.net
> 


More information about the Gc mailing list