Re: [Gc] SIGSEGVs avoided by calling GC_expand_hp

Ivan Maidanski ivmai at
Sat Jan 8 13:41:19 PST 2011

Hi Jan,

Sat, 8 Jan 2011 19:49:11 +0100 письмо от Jan St?pie? <jan at>:

> Hi everyone,
> During work on my thesis I've been developing a C application
> which uses both the GC and GLib. I've encountered a problem which seems
> to occur when a lot of small allocations are executed.
> I'm on 32 bit GNU/Linux 2.6.35. I've configured gc-7.1 with
> --disable-threads, --disable-cplusplus and --disable-shared and built a
> static library. I've instructed GLib to use GC's allocation functions
> instead of the ones from glibc and called GC_INIT before allocating
> anything.
> The SIGSEGV in GC_malloc_atomic is received at line malloc.c:225.
> *opp = obj_link(op);
> After checking in gdb it appears that the op variable tends to have
> small integer values lesser than 0xf00 which clearly aren't pointers.

In other words, GC_aobjfreelist contains a corrupted link pointer. Could you debug and find out who places that value to GC_aobjfreelist?
My guess is: GC had collected an object (which is now in GC_aobjfreelist) that is reachable from some untraceable memory and the application has modified that object (first word of it) some later (thus producing that corrupted link pointer).

Also, it would be good if you fetch the recent BDWGC snapshot from CVS and test whether the problem still exists. (If you don't want to fetch from the CVS, here's the snapshot as a tar-ball -


> Dereferencing them by obj_link causes a segfault.
> A workaround I've found is to call GC_expand_hp right after calling
> GC_INIT. I have to pass a really big value to solve the problem. For
> instance after passing 1024L * 1024L the SIGSEGV is still received but
> at mallocx.c:80 because of dereferencing a null pointer:
> sz = hhdr -> hb_sz;
> Passing 1024L * 1024L * 1024L to GC_expand_hp solves the problem but
> causes the program to use huge amounts of memory.
> I've tried to link the target program with libgc.a both statically and
> dynamically by creating a shared library which is statically linked
> with libgc.a. It didn't help.
> Are you aware of such kind of problems? I'd be really grateful for help
> in solving this issue.
> Best regards,
> -- 
> Jan St?pie? <jan at>
> _______________________________________________
> Gc mailing list
> Gc at

More information about the Gc mailing list