[Gc] crash in GC_reclaim_block in 6.3alpha6
hans.boehm at hp.com
Tue Jun 29 16:18:11 PDT 2004
Thanks for the beautifully small test case. This crash is
unlikely to occur, but is 100% reproducible, across architectures even,
with your test program.
I believe the fix consists of a one character change:
--- gc_priv.h.orig2 2004-06-29 14:56:35.000000000 -0700
+++ gc_priv.h 2004-06-29 15:16:52.000000000 -0700
@@ -578,7 +578,7 @@
# define ALIGNED_WORDS(n) ROUNDED_UP_WORDS(n)
-# define SMALL_OBJ(bytes) ((bytes) < (MAXOBJBYTES - EXTRA_BYTES))
+# define SMALL_OBJ(bytes) ((bytes) <= (MAXOBJBYTES - EXTRA_BYTES))
# define ADD_SLOP(bytes) ((bytes) + EXTRA_BYTES)
# ifndef MIN_WORDS
/* MIN_WORDS is the size of the smallest allocated object. */
The collector treats "large" objects differently from "small" ones,
and it wasn't completely consistent about the boundary between the two.
I would have expected such a bug to introduce other problems as well.
But I couldn't immediately identify any. It was clearly also present
in version 6.2, and probably earlier.
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Zoltan Varga
> Sent: Friday, June 25, 2004 1:13 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] crash in GC_reclaim_block in 6.3alpha6
> I'm getting crashes in GC_reclaim_block when
> using GC_malloc_atomic under solaris 9 in 64bit mode.
> Here is a test case:
> #include <gc.h>
> void main ()
> int i;
> GC_all_interior_pointers = 0;
> for (i = 0; i < 4096; ++i)
> GC_malloc_atomic (4096);
> The problem seems to be that GC_obj_kinds ->ok_reclaim_list is
> NULL. I think this is because
> GC_generic_malloc does not call GC_alloc_reclaim_list
> for large objects.
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc