[Gc] Problem with GC on FreeBSD

Vitaly Magerya vmagerya at gmail.com
Wed Apr 18 06:37:17 PDT 2012

Ivan Maidanski <ivmai at mail.ru> wrote:
> Hi Vitaly,
> 1. Please checkout the recent bdwgc/master snapshot (according to line
> numbers you use the version before a bug was fixed in fnlz_mlc.c).

OK, just tried that. One difference is that disclaim_test now
performs "Threaded disclaim test" (it did unthreaded before). This
doesn't change the segfault though; here's the new backtrace:

#0  0x000000080086c1a1 in GC_finalized_malloc (client_lb=24, fclos=0x401690) at fnlz_mlc.c:145
#1  0x0000000000400ecf in pair_new (car=0x84eda0, cdr=0x869b40) at tests/disclaim_test.c:114
#2  0x000000000040125c in test (data=0x0) at tests/disclaim_test.c:178
#3  0x0000000800869ee7 in GC_inner_start_routine (sb=0x7fffffbfdf90, arg=0x845f90) at pthread_start.c:56
#4  0x00000008008648b6 in GC_call_with_stack_base (fn=0x800869ea0 <GC_inner_start_routine>, arg=0x845f90) at misc.c:1622
#5  0x000000080086b0dc in GC_start_routine (arg=0x845f90) at pthread_support.c:1613
#6  0x0000000800a9f274 in pthread_getprio () from /lib/libthr.so.3
#7  0x0000000000000000 in ?? ()

> 2. I guess USE_CUSTOM_SPECIFIC is defined for FreeBSD in
> thread_local_alloc.h, if the bug is probably in GC_setspecific.
> 3. Try to compile with explicit -D USE_PTHREAD_SPECIFIC (probably we could
> use it permanently for FreeBSD but it would be good to find out what's wrong
> in GC_setspecific)

This seems to help: disclaim_test now passes, and STklos works
properly too, but only if I compile libgc with --enable-gc-debug;
without that STklos segfaults in the middle of it's test suite (even
before threading tests); the crash is in libgc, here's the backtrace:

#0  0x0000000801184c3e in GC_clear_fl_marks (q=0x64636261 <Error reading address 0x64636261: Bad address>) at alloc.c:760
#1  0x0000000801184eaf in GC_finish_collection () at alloc.c:879
#2  0x0000000801184690 in GC_try_to_collect_inner (stop_func=0x801183f00 <GC_never_stop_func>) at alloc.c:472
#3  0x000000080118595e in GC_collect_or_expand (needed_blocks=1, ignore_off_page=0, retry=0) at alloc.c:1239
#4  0x0000000801185c71 in GC_allocobj (gran=4, kind=1) at alloc.c:1328
#5  0x000000080118beec in GC_generic_malloc_inner (lb=48, k=1) at malloc.c:122
#6  0x000000080118d441 in GC_generic_malloc_many (lb=48, k=1, result=0x8013a3bc0) at mallocx.c:425
#7  0x0000000801196455 in GC_malloc (bytes=32) at thread_local_alloc.c:175
#8  0x0000000000417aef in STk_clone_frame (f=0x903930) at env.c:400
[... STklos stuff below ...]

The offending address (q=0x64636261) is GC_obj_kinds[0].ok_freelist[36];
looks like corrupted data?

Moreover, if I build libgc with gc-assertions and gc-debug,
disclaim_test fails again. More precisely, sometimes it segfaults,
sometimes it fails with "Assertion failure: dbg_mlc.c:843", and
other times it passes.
With --enable-gc-assertions and without --enable-gc-debug disclaim_test
always segfaults:

#0  0x000000080086136f in GC_is_marked (p=0x30e00000001) at mark.c:233
#1  0x000000080085642f in GC_check_fl_marks (q=0xa813c0 "\001") at alloc.c:739
#2  0x000000080086be9c in GC_check_tls_for (p=0x842ac0) at thread_local_alloc.c:328
#3  0x000000080086deee in GC_check_tls () at pthread_support.c:316
#4  0x00000008008565ec in GC_finish_collection () at alloc.c:812
#5  0x0000000800855e10 in GC_try_to_collect_inner (stop_func=0x8008554c0 <GC_never_stop_func>) at alloc.c:472
#6  0x00000008008573ae in GC_collect_or_expand (needed_blocks=1, ignore_off_page=0, retry=0) at alloc.c:1239
#7  0x00000008008576f1 in GC_allocobj (gran=2, kind=4) at alloc.c:1328
#8  0x000000080085ebec in GC_generic_malloc_inner (lb=32, k=4) at malloc.c:122
#9  0x00000008008607da in GC_generic_malloc_many (lb=32, k=4, result=0xb08d28) at mallocx.c:425
#10 0x0000000800871203 in GC_finalized_malloc (client_lb=24, fclos=0x401690) at fnlz_mlc.c:152
#11 0x0000000000400ecf in pair_new (car=0xb45da0, cdr=0x0) at tests/disclaim_test.c:114
#12 0x000000000040125c in test (data=0x0) at tests/disclaim_test.c:178
#13 0x000000080086de07 in GC_inner_start_routine (sb=0x7fffff5faf90, arg=0x841fc0) at pthread_start.c:56
#14 0x00000008008678c6 in GC_call_with_stack_base (fn=0x80086ddc0 <GC_inner_start_routine>, arg=0x841fc0) at misc.c:1622
#15 0x000000080086fc7c in GC_start_routine (arg=0x841fc0) at pthread_support.c:1613
#16 0x0000000800aa4274 in pthread_getprio () from /lib/libthr.so.3
#17 0x0000000000000000 in ?? ()

(I'm assuming these backtraces actually show something interesting;
tell me if I should skip them in the future).

More information about the Gc mailing list