[Gc] Problem with GC on FreeBSD

Vitaly Magerya vmagerya at gmail.com
Sun Apr 22 12:08:31 PDT 2012


Ivan Maidanski <ivmai at mail.ru> wrote:
> Hi Petter, Vitaly and Hans,
>
> Vitaly -
> 1. Please test branch 'fix-freelist-check-and-specific' (it should only fix
> the problem for --enable-gc-assertions)

Here's the summary of tests I made against fix-freelist-check-and-specific
branch (hopefully I didn't make any stupid mistakes during testing,
as there are many configurations; feel free to ask for a re-test):

With USE_CUSTOM_SPECIFIC, without gc-debug, without gc-assertions:
    all tests pass, stklos hangs on thread tests

With USE_CUSTOM_SPECIFIC, without gc-debug, with gc-assertions:
    all tests pass, stklos hangs on thread tests

With USE_CUSTOM_SPECIFIC, with gc-debug, without gc-assertions:
    disclaim_test segfaults (it passes on a very rare occasion)

Backtrace:

#0  0x000000080086c1f1 in GC_finalized_malloc (client_lb=24,
fclos=0x401690) at fnlz_mlc.c:145
#1  0x0000000000400ecf in pair_new (car=0xba9ac0, cdr=0x0) at
tests/disclaim_test.c:114
#2  0x000000000040125c in test (data=0x0) at tests/disclaim_test.c:178
#3  0x0000000800869f37 in GC_inner_start_routine (sb=0x7fffff9fcf90,
arg=0x845f90) at pthread_start.c:56
[...]

With USE_CUSTOM_SPECIFIC, with gc-debug, with gc-assertions:
    disclaim_test segfaults (sometimes)

With USE_PTHREAD_SPECIFIC, without gc-debug, without gc-assertions:
    all tests pass, stklos segfaults

With USE_PTHREAD_SPECIFIC, without gc-debug, with assertions:
    all tests pass, stklos fails before threading tests:
    "Assertion failure: thread_local_alloc.c:176".

Here's the backtrace:

#0  0x0000000801866a7c in thr_kill () from /lib/libc.so.7
#1  0x0000000801903d3b in abort () from /lib/libc.so.7
#2  0x000000080119a97f in GC_malloc (bytes=56) at thread_local_alloc.c:175
[... STklos stuff ...]

With USE_PTHREAD_SPECIFIC, with gc-debug, without gc-assertions:
    disclaim_test sometimes segfaults (rarely)

Backtrace:

#0  0x00000008008635fd in GC_size (p=0x0) at misc.c:452
#1  0x0000000800858c87 in GC_debug_free_inner (p=0x916ac0) at dbg_mlc.c:849
#2  0x0000000800869ea6 in GC_delete_gc_thread (t=0x916ac0) at
pthread_support.c:571
#3  0x000000080086a9dd in GC_pthread_join (thread=0x801008400,
retval=0x0) at pthread_support.c:1370
#4  0x00000000004013b6 in main () at tests/disclaim_test.c:212

(Sometimes the values of p and t at #1 and #2 differ).

With USE_PTHREAD_SPECIFIC, with gc-debug, with gc-assertions:
    disclaim_test sometimes fails: "Assertion failure: dbg_mlc.c:843"

Here's the backtrace:

#0  0x0000000800d17a7c in thr_kill () from /lib/libc.so.7
#1  0x0000000800db4d3b in abort () from /lib/libc.so.7
#2  0x0000000800859a6f in GC_debug_free_inner (p=0x91aac0) at dbg_mlc.c:843
#3  0x000000080086ecc0 in GC_delete_gc_thread (t=0x91aac0) at
pthread_support.c:571
#4  0x000000080086ffc0 in GC_pthread_join (thread=0x801408400,
retval=0x0) at pthread_support.c:1370
#5  0x00000000004013b6 in main () at tests/disclaim_test.c:212

The error happens because GC_base(p) at dbg_mlc.c:842 returns 0. It does
so because of HBLK_IS_FREE(candidate_hdr) == 0 condition at misc.c:417.

> 2. I'm still puzzled what's the problem USE_CUSTOM_SPECIFIC (which is
> defined by default for FreeBSD for now unless you set USE_PTHREAD_SPECIFIC)
> - looks like some thread is not unregistered (i.e. GC_remove_specific not
> called) on exit.

GC_remove_specific is indeed never called prior to the segfault (in
configuration where USE_CUSTOM_SPECIFIC and --enable-gc-debug are
used). It is called without --enable-gc-debug, it is called on those
rare occasions when disclaim_test passes, but not when it segfaults.


More information about the Gc mailing list