Discussion:
[Gc] Problem with GC on FreeBSD
(too old to reply)
Vitaly Magerya
2012-04-17 18:01:22 UTC
Permalink
Hi, folks. A number of programs that use libgc fail on FreeBSD; I'm
not completely sure this is gc's fault, but it does fail it's own
disclaim_test, so I need help fixing that.

That was the short version. The long one is this. Starting with
FreeBSD 9.0 a number of ports that use libgc fail during build; the
ones I care about are STklos [1] and Gauche [2]. Both currently use
libgc 7.1, both segfault on startup inside GC_FreeBSDGetDataStart
(os_dep.c:1654; I can provide backtraces on request), and both
worked fine on FreeBSD 7.x and 8.x.

I tried updating libgc from the ancient 7.1 to 7.2-alpha6 and to
current git (from github.com/ivmai/bdwgc) -- this helps a little.
The programs don't fail immediately on startup, but STklos hangs
on one of it's unit tests (while testing threads), and Gauche crashes
while compiling (or loading?) a thread-related library (the crash
is not inside of libgc).

Now while I'm not completely sure the new problems are caused by
the garbage collector, here's one datapoint: libgc fails one of
it's own regression tests (disclaim_test), but only when it's
configured with --enable-threads=posix and --enable-gc-debug (it
passes all the tests without threads or without gc-debug).

When I run .libs/disclaim_test (from the latest bdwgc git) manually
it produces this output:

$ ./.libs/disclaim_test
Unthreaded disclaim test.
Segmentation fault

GDB shows that the crash is in GC_finalized_malloc; here's the
backtrace:

#0 0x000000080086c181 in GC_finalized_malloc (client_lb=24,
fclos=0x401460) at fnlz_mlc.c:142
#1 0x0000000000400d9f in pair_new (car=0x0, cdr=0x0) at
tests/disclaim_test.c:105
#2 0x000000000040112c in test (data=0x0) at tests/disclaim_test.c:169
#3 0x0000000000401201 in main () at tests/disclaim_test.c:212

It appears that GC_getspecific(GC_thread_key) call at fnlz_mlc.c:139
returns NULL and everything goes downhill from that.

I tesed this on a 2-core machine running FreeBSD 9.0 (amd64), but
it seems that all FreeBSD versions are affected -- see build logs
at [3] (devel/boehm-gc-threaded is the only one that fails regression
tests; that is the version compiled with threads).

So, how do I debug this particular error? What can be causing it?

(The question I actually want to ask is how to fix STklos and Guile,
but I'll start with working regressios tests first).

[1] http://www.freshports.org/lang/stklos
[2] http://www.freshports.org/lang/gauche
[3] http://redports.org/buildarchive/20120417134051-41852/
Ivan Maidanski
2012-04-17 21:02:05 UTC
Permalink
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).
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)

Regards.
Post by Vitaly Magerya
Hi, folks. A number of programs that use libgc fail on FreeBSD; I'm
not completely sure this is gc's fault, but it does fail it's own
disclaim_test, so I need help fixing that.
That was the short version. The long one is this. Starting with
FreeBSD 9.0 a number of ports that use libgc fail during build; the
ones I care about are STklos [1] and Gauche [2]. Both currently use
libgc 7.1, both segfault on startup inside GC_FreeBSDGetDataStart
(os_dep.c:1654; I can provide backtraces on request), and both
worked fine on FreeBSD 7.x and 8.x.
I tried updating libgc from the ancient 7.1 to 7.2-alpha6 and to
current git (from github.com/ivmai/bdwgc) -- this helps a little.
The programs don't fail immediately on startup, but STklos hangs
on one of it's unit tests (while testing threads), and Gauche crashes
while compiling (or loading?) a thread-related library (the crash
is not inside of libgc).
Now while I'm not completely sure the new problems are caused by
the garbage collector, here's one datapoint: libgc fails one of
it's own regression tests (disclaim_test), but only when it's
configured with --enable-threads=posix and --enable-gc-debug (it
passes all the tests without threads or without gc-debug).
When I run .libs/disclaim_test (from the latest bdwgc git) manually
$ ./.libs/disclaim_test
Unthreaded disclaim test.
Segmentation fault
GDB shows that the crash is in GC_finalized_malloc; here's the
#0 0x000000080086c181 in GC_finalized_malloc (client_lb=24,
fclos=0x401460) at fnlz_mlc.c:142
#1 0x0000000000400d9f in pair_new (car=0x0, cdr=0x0) at
tests/disclaim_test.c:105
#2 0x000000000040112c in test (data=0x0) at tests/disclaim_test.c:169
#3 0x0000000000401201 in main () at tests/disclaim_test.c:212
It appears that GC_getspecific(GC_thread_key) call at fnlz_mlc.c:139
returns NULL and everything goes downhill from that.
I tesed this on a 2-core machine running FreeBSD 9.0 (amd64), but
it seems that all FreeBSD versions are affected -- see build logs
at [3] (devel/boehm-gc-threaded is the only one that fails regression
tests; that is the version compiled with threads).
So, how do I debug this particular error? What can be causing it?
(The question I actually want to ask is how to fix STklos and Guile,
but I'll start with working regressios tests first).
[1] http://www.freshports.org/lang/stklos
[2] http://www.freshports.org/lang/gauche
[3] http://redports.org/buildarchive/20120417134051-41852/
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Vitaly Magerya
2012-04-18 13:37:17 UTC
Permalink
Post by Ivan Maidanski
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 ?? ()
Post by Ivan Maidanski
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).
Ivan Maidanski
2012-04-18 14:49:02 UTC
Permalink
Hi Vitaly,

Please try release branch of bdwgc.
Post by Vitaly Magerya
Post by Ivan Maidanski
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
#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 ?? ()
Post by Ivan Maidanski
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
#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
#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).
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Vitaly Magerya
2012-04-18 22:25:38 UTC
Permalink
Post by Ivan Maidanski
Hi Vitaly,
Please try release branch of bdwgc.
OK, tried that (with release branch of libatomic_ops). There seems to
be a difference in that the configure script of release branch does not
enable THREAD_LOCAL_ALLOC for FreeBSD, so I tested without it (tell me
if I should try enabling it manually).

Without --enable-gc-debug, all 11 tests pass, but STklos hangs (on
threading tests) -- not every time, but often. This is both with and
without --enable-assertions.

With --enable-gc-debug, all 12 tests pass, and STklos crashes with SIGBUS
(before threading tests) inside libgc:
#0 0x000000080118c2cd in GC_malloc (lb=56) at malloc.c:257
[... STklos stuff below ...]

This problems seems to come from GC_objfreelist[4], which is
0x3300010000000b at the point of crash.

With --enable-gc-debug and --enable-gc-assertions, all 12 tests pass,
and STklos aborts saying "Assertion failure: malloc.c:256" (it's the
same problem as above, only caught one line earlier).
Petter Urkedal
2012-04-18 17:07:02 UTC
Permalink
Post by Vitaly Magerya
Post by Ivan Maidanski
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
#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
#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 ?? ()
Hi Vitaly,

I'll focus on this part first, since it's most directly related to the
code I wrote. It seems the thread local freelists are the problem,
maybe they are not initialized. The thread local key should be working
now with -D USE_PTHREAD_SPECIFIC, right? But I'm wondering whether
GC_init_thread_local gets called. It may be worth trying to change
pthread_create to GC_pthread_create in disclaim_test.c (or insert a call
to GC_unregister_my_thread inside the thread call-back). If it makes a
difference, this might be relevant for the above segfault, as well.
Post by Vitaly Magerya
(I'm assuming these backtraces actually show something interesting;
tell me if I should skip them in the future).
They're useful :-)

Petter
Ivan Maidanski
2012-04-18 18:19:22 UTC
Permalink
Hi Petter and Vitaly,
Post by Ivan Maidanski
Post by Vitaly Magerya
Post by Ivan Maidanski
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
#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
#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 ?? ()
Hi Vitaly,
I'll focus on this part first, since it's most directly related to the
code I wrote. It seems the thread local freelists are the problem,
maybe they are not initialized. The thread local key should be working
now with -D USE_PTHREAD_SPECIFIC, right? But I'm wondering whether
GC_init_thread_local gets called. It may be worth trying to change
pthread_create to GC_pthread_create in disclaim_test.c (or insert a call
to GC_unregister_my_thread inside the thread call-back). If it makes a
difference, this might be relevant for the above segfault, as well.
As Vitaly reported, disclaim_test had been single-threaded (before latest checkout) and crashed too, so GC_init_thread_local seems to be called (from GC_init). I asked Vitaly to test "release" branch (which has no "disclaim" functionality).
Post by Ivan Maidanski
Post by Vitaly Magerya
(I'm assuming these backtraces actually show something interesting;
tell me if I should skip them in the future).
They're useful :-)
Sorry Petter, smile char is not appropriate here as might be misleading. My opinion - it is ok to put such (non-big) traces.

Regards.
Post by Ivan Maidanski
Petter
Petter Urkedal
2012-04-18 19:51:37 UTC
Permalink
Hi Ivan and Vitaly,
Post by Ivan Maidanski
Hi Petter and Vitaly,
Post by Ivan Maidanski
Post by Vitaly Magerya
Post by Ivan Maidanski
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
#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
#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 ?? ()
Hi Vitaly,
I'll focus on this part first, since it's most directly related to the
code I wrote. It seems the thread local freelists are the problem,
maybe they are not initialized. The thread local key should be working
now with -D USE_PTHREAD_SPECIFIC, right? But I'm wondering whether
GC_init_thread_local gets called. It may be worth trying to change
pthread_create to GC_pthread_create in disclaim_test.c (or insert a call
to GC_unregister_my_thread inside the thread call-back). If it makes a
difference, this might be relevant for the above segfault, as well.
Corr: "GC_unregister_my_thread" should read "GC_register_my_thread".
Post by Ivan Maidanski
As Vitaly reported, disclaim_test had been single-threaded (before latest checkout) and crashed too, so GC_init_thread_local seems to be called (from GC_init). I asked Vitaly to test "release" branch (which has no "disclaim" functionality).
The test case was single threaded due to the missing include you fixed
recently. Nevertheless, it he ran the test on a multi-threaded libgc
which could expose such an issue.

I tried to trace how GC_init_thread_local gets called without the use of
GC_pthread_create or GC_register_my_thread. The only path I can find is
from a redirected pthread_create in case GC_USE_LD_WRAP is enabled. Am
I missing something?

Petter
Vitaly Magerya
2012-04-18 22:25:53 UTC
Permalink
Post by Petter Urkedal
Post by Petter Urkedal
I'll focus on this part first, since it's most directly related to the
code I wrote. It seems the thread local freelists are the problem,
maybe they are not initialized. The thread local key should be working
now with -D USE_PTHREAD_SPECIFIC, right?
Right.
Post by Petter Urkedal
Post by Petter Urkedal
But I'm wondering whether
GC_init_thread_local gets called.
It is (via GC_init => GC_init_parallel => GC_init_thread_local).
Post by Petter Urkedal
Post by Petter Urkedal
It may be worth trying to change
pthread_create to GC_pthread_create in disclaim_test.c
Just tried that, got the same crash (with slightly different numbers,
but basically the same).

Note that I don't always get the crash in the debugger; sometimes it
just hangs (especially if I don't disable SIGUSR1 & SIGUSR2 interception).
Post by Petter Urkedal
Post by Petter Urkedal
(or insert a call
to GC_unregister_my_thread inside the thread call-back). If it makes a
difference, this might be relevant for the above segfault, as well.
Corr: "GC_unregister_my_thread" should read "GC_register_my_thread".
Doesn't seem to change anything (i.e. the same crash).

Is this the correct way to call it?

/* main thread */
GC_allow_register_threads();

/* subthreads */
GC_call_with_stack_base(GC_register_my_thread, NULL);
Petter Urkedal
2012-04-19 00:18:00 UTC
Permalink
Post by Vitaly Magerya
Post by Petter Urkedal
Post by Petter Urkedal
I'll focus on this part first, since it's most directly related to the
code I wrote. It seems the thread local freelists are the problem,
maybe they are not initialized. The thread local key should be working
now with -D USE_PTHREAD_SPECIFIC, right?
Right.
Post by Petter Urkedal
Post by Petter Urkedal
But I'm wondering whether
GC_init_thread_local gets called.
It is (via GC_init => GC_init_parallel => GC_init_thread_local).
That covers the main thread.
Post by Vitaly Magerya
Post by Petter Urkedal
Post by Petter Urkedal
It may be worth trying to change
pthread_create to GC_pthread_create in disclaim_test.c
Just tried that, got the same crash (with slightly different numbers,
but basically the same).
Thanks for testing it. So, it seems was wrong about this.
Post by Vitaly Magerya
Note that I don't always get the crash in the debugger; sometimes it
just hangs (especially if I don't disable SIGUSR1 & SIGUSR2 interception).
Post by Petter Urkedal
Post by Petter Urkedal
(or insert a call
to GC_unregister_my_thread inside the thread call-back). If it makes a
difference, this might be relevant for the above segfault, as well.
Corr: "GC_unregister_my_thread" should read "GC_register_my_thread".
Doesn't seem to change anything (i.e. the same crash).
Is this the correct way to call it?
/* main thread */
GC_allow_register_threads();
/* subthreads */
GC_call_with_stack_base(GC_register_my_thread, NULL);
Ah, I'm actually using GC_pthread_create myself, but this looks right
according to the documentation.

Anyway, I can reproduce the issue occasionally with when I
--enable-gc-assertions, so I can take the disclaim_test-issue from here.
Petter Urkedal
2012-04-19 17:05:29 UTC
Permalink
I think I found the bug which makes disclaim_test fail. The bug is also
reproducible using the regular GC_malloc if the library is compiled with
threads and --enable-gc-assertions, and the line

GC_ASSERT(GC_is_thread_tsd_valid(tsd));

is commented out from thread_local_alloc.c. I attach a brewed down
version on disclaim_test.c which uses GC_malloc along with the change to
thread_local_alloc.c needed to unveil the bug. I tried git-bisect to
located the offending commit, but this seems to go as far back as I was
able to compile, which includes 3c50a689ca85f4fe56afbc8da9e894c4cc3af845
(gc7.0alpha5 tarball import).

The issue is that GC_check_tls goes though the thread-local structures
of other threads. So, it seems GC_check_tls picks up an object from the
free list which is just about to be unlinked and returned to the caller
by another thread. Therefore the issue is only seen when assertions are
enabled. On the other hand the locking done by
GC_is_thread_tsd_valid(tsd) seems sufficient to hide the issue, even
though it does not surround the actual unlinking of the free list. This
can be verified by replacing the "GC_is_thread_tsd_valid(tsd)" call with
"LOCK(); UNLOCK();"

Ivan, Hans: Any suggestion what's the best way to fix this?
Petter Urkedal
2012-04-19 17:27:59 UTC
Permalink
Post by Petter Urkedal
is commented out from thread_local_alloc.c. I attach a brewed down
version on disclaim_test.c which uses GC_malloc along with the change to
thread_local_alloc.c needed to unveil the bug. I tried git-bisect to
And here comes the promised attachments.
Petter Urkedal
2012-04-20 08:23:24 UTC
Permalink
Hi Ivan,

I pushed a suggestion for a fix to
https://github.com/paurkedal/bdwgc/compare/fix-freelist-checks
While traversing the free-list, it it re-reads the pointer to the
current node before accepting its next-pointer, and bails out if it has
changed. That way, it won't try to follow a pointer which may be been
modified after the object was returned to the client. It may perform
the mark-check on a just allocated object, but that should be harmless.
The solution is a bit unorthodox, so you may want to have a good look.

Petter
Post by Petter Urkedal
I think I found the bug which makes disclaim_test fail. The bug is also
reproducible using the regular GC_malloc if the library is compiled with
threads and --enable-gc-assertions, and the line
GC_ASSERT(GC_is_thread_tsd_valid(tsd));
is commented out from thread_local_alloc.c. I attach a brewed down
version on disclaim_test.c which uses GC_malloc along with the change to
thread_local_alloc.c needed to unveil the bug. I tried git-bisect to
located the offending commit, but this seems to go as far back as I was
able to compile, which includes 3c50a689ca85f4fe56afbc8da9e894c4cc3af845
(gc7.0alpha5 tarball import).
The issue is that GC_check_tls goes though the thread-local structures
of other threads. So, it seems GC_check_tls picks up an object from the
free list which is just about to be unlinked and returned to the caller
by another thread. Therefore the issue is only seen when assertions are
enabled. On the other hand the locking done by
GC_is_thread_tsd_valid(tsd) seems sufficient to hide the issue, even
though it does not surround the actual unlinking of the free list. This
can be verified by replacing the "GC_is_thread_tsd_valid(tsd)" call with
"LOCK(); UNLOCK();"
Ivan, Hans: Any suggestion what's the best way to fix this?
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Ivan Maidanski
2012-04-22 13:07:52 UTC
Permalink
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)
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.

Petter -
I'm not sure about the the correctness of the fix proposed by your. So, I put it into another branch for a while - https://github.com/ivmai/bdwgc/tree/fix-freelist-check-and-specific
I've split your patch into a refactoring one and the fix itself (with minor modifications like 2nd AO_load_acq -> AO_load).

The alternate solution could be to call the check with the stopped world (but it seems to me not a trivial task to move the check there).

Hans -
1. Could you express your opinion about the proposed fix - https://github.com/ivmai/bdwgc/commit/c3dae88f9cc38c75d8450c0946fe9c4206cfd592
2. Should GC be disabled in GC_setspecific for tse allocation? - https://github.com/ivmai/bdwgc/commit/b71fcac4d1b65e2f412cf7edd3a6979aeb870a33
(I can't make it crash with implicit GC_gcollect_inner but I'm not sure whether GC there is always harmless.)

Regards.
Post by Petter Urkedal
Hi Ivan,
I pushed a suggestion for a fix to
https://github.com/paurkedal/bdwgc/compare/fix-freelist-checks
While traversing the free-list, it it re-reads the pointer to the
current node before accepting its next-pointer, and bails out if it has
changed. That way, it won't try to follow a pointer which may be been
modified after the object was returned to the client. It may perform
the mark-check on a just allocated object, but that should be harmless.
The solution is a bit unorthodox, so you may want to have a good look.
Petter
Post by Petter Urkedal
I think I found the bug which makes disclaim_test fail. The bug is also
reproducible using the regular GC_malloc if the library is compiled with
threads and --enable-gc-assertions, and the line
GC_ASSERT(GC_is_thread_tsd_valid(tsd));
is commented out from thread_local_alloc.c. I attach a brewed down
version on disclaim_test.c which uses GC_malloc along with the change to
thread_local_alloc.c needed to unveil the bug. I tried git-bisect to
located the offending commit, but this seems to go as far back as I was
able to compile, which includes 3c50a689ca85f4fe56afbc8da9e894c4cc3af845
(gc7.0alpha5 tarball import).
The issue is that GC_check_tls goes though the thread-local structures
of other threads. So, it seems GC_check_tls picks up an object from the
free list which is just about to be unlinked and returned to the caller
by another thread. Therefore the issue is only seen when assertions are
enabled. On the other hand the locking done by
GC_is_thread_tsd_valid(tsd) seems sufficient to hide the issue, even
though it does not surround the actual unlinking of the free list. This
can be verified by replacing the "GC_is_thread_tsd_valid(tsd)" call with
"LOCK(); UNLOCK();"
Ivan, Hans: Any suggestion what's the best way to fix this?
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Petter Urkedal
2012-04-22 15:14:12 UTC
Permalink
Post by Ivan Maidanski
Petter -
I'm not sure about the the correctness of the fix proposed by your. So, I put it into another branch for a while - https://github.com/ivmai/bdwgc/tree/fix-freelist-check-and-specific
Sure.
Post by Ivan Maidanski
I've split your patch into a refactoring one and the fix itself (with minor modifications like 2nd AO_load_acq -> AO_load).
AO_load seems more logical yes. (Though, if I understand the AO
documentation right, the first AO_load_acquire should ensure ordering of
the two reads even if the latter was a regular read.)
Post by Ivan Maidanski
The alternate solution could be to call the check with the stopped world (but it seems to me not a trivial task to move the check there).
Yes, that should work, even if a thread is suspended during a
thread-local allocation.
Vitaly Magerya
2012-04-22 19:08:31 UTC
Permalink
Post by Ivan Maidanski
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.
Post by Ivan Maidanski
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.
Ivan Maidanski
2012-05-02 14:04:44 UTC
Permalink
Hi Vitaly,
Post by Vitaly Magerya
Post by Ivan Maidanski
Hi Vitaly,
1. There's a bug associated with enable-gc-debug - Petter already discovered
the cause and te proper fix will be applied soon
Should I test his repo as it is, or wait until the fix hits your master branch?
The patches are already in master.
Post by Vitaly Magerya
Post by Ivan Maidanski
2. If gc-debug is off then only stklos (not included into bdwgc) hangs
regardless of USE_xxx_SPECIFIC, right?
Right, except that with USE_CUSTOM_SPECIFIC STklos hangs during
thread-related regression tests, but with USE_PTHREAD_SPECIFIC it
segfaults (inside GC_clear_fl_marks if I'm not mistaken) prior to
those.
I think there's no difference.
Post by Vitaly Magerya
There is a similar problem with Gauche, but I did not test it in
different configurations (I will once other problems are dealt with).
Just to revise, you see this bug only in FreeBSD 8 but not in Linux or older BSD, right?
Post by Vitaly Magerya
Post by Ivan Maidanski
I'll try to check stklos problem tomorrow.
Sorry, have no access to FreeBSD and Linux these days (until May 12).

Regards.
Post by Vitaly Magerya
Thank you.
Vitaly Magerya
2012-05-02 21:59:25 UTC
Permalink
Post by Ivan Maidanski
Post by Vitaly Magerya
Should I test his repo as it is, or wait until the fix hits your master branch?
The patches are already in master.
OK. All the tests now pass in all configurations.
Post by Ivan Maidanski
Post by Vitaly Magerya
Post by Ivan Maidanski
2. If gc-debug is off then only stklos (not included into bdwgc) hangs
regardless of USE_xxx_SPECIFIC, right?
Right, except that with USE_CUSTOM_SPECIFIC STklos hangs during
thread-related regression tests, but with USE_PTHREAD_SPECIFIC it
segfaults (inside GC_clear_fl_marks if I'm not mistaken) prior to
those.
I think there's no difference.
Well, it would be good if this was the same problem, not two different ones.
Post by Ivan Maidanski
Just to revise, you see this bug only in FreeBSD 8 but not in Linux or older BSD, right?
The problems with libgc 7.2 began in FreeBSD 9.0, and where not
present in 8.x or 7.x.

I only tested current master on FreeBSD 9.0... until this evening. I
just managed to reproduce the same problem with STklos on Linux in at
least one configuration, and it is completely absent in another, so
this may not be a libgc problem.
Post by Ivan Maidanski
Sorry, have no access to FreeBSD and Linux these days (until May 12).
As this may be a false alert, please let me run more tests and get
back to you before you invest more time in this issue.

Ivan Maidanski
2012-04-23 17:58:40 UTC
Permalink
Hi Petter,

I confirm a problem with disclaim_test in 'fix-freelist-check-and-specific' on Linux/x86:

CFLAGS=-DUSE_CUSTOM_SPECIFIC ./configure --enable-gc-debug

Threaded disclaim test.
Segmentation fault.

I haven't time to run in under gdb or test other scenarios today.

Regards.
Post by Vitaly Magerya
Post by Ivan Maidanski
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,
all tests pass, stklos hangs on thread tests
all tests pass, stklos hangs on thread tests
disclaim_test segfaults (it passes on a very rare occasion)
#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
[...]
disclaim_test segfaults (sometimes)
all tests pass, stklos segfaults
"Assertion failure: thread_local_alloc.c:176".
#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 ...]
disclaim_test sometimes segfaults (rarely)
#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).
disclaim_test sometimes fails: "Assertion failure: dbg_mlc.c:843"
#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.
Post by Ivan Maidanski
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.
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Petter Urkedal
2012-04-24 06:37:56 UTC
Permalink
Hi Ivan,

On closer inspection this looks like the bug I wrote about in
"Segfault for certain sizes of GC_Thread_Rep" (2011-09-15 00:03).
It can be reproduced with the attached diff and test case using
--enable-gc-debug and for new versions, --disable-disclaim. The
conditions that must be met to trigger the bug is

* GC_Thread_Rep is at least 560 bytes.
* The GC_INTERNAL_MALLOC expands to GC_debug_generic_malloc_inner.
* GC_all_interior_pointers is 0.

GC_debug_generic_malloc_inner stores its metadata at the beginning of
the objects. That's what caused the problem for GC_finalized_malloc
before we moved the header to the end and added the
GC_set_all_interior_pointers(0) to the test case.

Is debug allocation supposed to work with GC_all_interior_pointers = 0?

Petter
Post by Ivan Maidanski
Hi Petter,
CFLAGS=-DUSE_CUSTOM_SPECIFIC ./configure --enable-gc-debug
Threaded disclaim test.
Segmentation fault.
I haven't time to run in under gdb or test other scenarios today.
Regards.
Post by Vitaly Magerya
Post by Ivan Maidanski
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,
all tests pass, stklos hangs on thread tests
all tests pass, stklos hangs on thread tests
disclaim_test segfaults (it passes on a very rare occasion)
#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
[...]
disclaim_test segfaults (sometimes)
all tests pass, stklos segfaults
"Assertion failure: thread_local_alloc.c:176".
#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 ...]
disclaim_test sometimes segfaults (rarely)
#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).
disclaim_test sometimes fails: "Assertion failure: dbg_mlc.c:843"
#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.
Post by Ivan Maidanski
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.
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Ivan Maidanski
2012-04-28 12:07:29 UTC
Permalink
Hi Petter,

Sorry for the delay.

To my current understanding, the problem caused by missing GC_register_displacement(sizeof(oh)) (i.e. light "debugging_started") in GC_store_debug_info_inner. What do you think? (I guess I'll have some time to check your test case with such a fix tomorrow).

Regards.
Post by Petter Urkedal
Hi Ivan,
On closer inspection this looks like the bug I wrote about in
"Segfault for certain sizes of GC_Thread_Rep" (2011-09-15 00:03).
It can be reproduced with the attached diff and test case using
--enable-gc-debug and for new versions, --disable-disclaim. The
conditions that must be met to trigger the bug is
* GC_Thread_Rep is at least 560 bytes.
* The GC_INTERNAL_MALLOC expands to GC_debug_generic_malloc_inner.
* GC_all_interior_pointers is 0.
GC_debug_generic_malloc_inner stores its metadata at the beginning of
the objects. That's what caused the problem for GC_finalized_malloc
before we moved the header to the end and added the
GC_set_all_interior_pointers(0) to the test case.
Is debug allocation supposed to work with GC_all_interior_pointers = 0?
Petter
Post by Ivan Maidanski
Hi Petter,
I confirm a problem with disclaim_test in 'fix-freelist-check-and-specific'
CFLAGS=-DUSE_CUSTOM_SPECIFIC ./configure --enable-gc-debug
Threaded disclaim test.
Segmentation fault.
I haven't time to run in under gdb or test other scenarios today.
Regards.
Post by Vitaly Magerya
Post by Ivan Maidanski
Hi Petter, Vitaly and Hans,
Vitaly -
1. Please test branch 'fix-freelist-check-and-specific' (it should only
fix
Post by Ivan Maidanski
Post by Vitaly Magerya
Post by Ivan Maidanski
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,
all tests pass, stklos hangs on thread tests
all tests pass, stklos hangs on thread tests
disclaim_test segfaults (it passes on a very rare occasion)
#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
[...]
disclaim_test segfaults (sometimes)
all tests pass, stklos segfaults
"Assertion failure: thread_local_alloc.c:176".
#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 ...]
disclaim_test sometimes segfaults (rarely)
#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
Post by Ivan Maidanski
Post by Vitaly Magerya
#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).
disclaim_test sometimes fails: "Assertion failure: dbg_mlc.c:843"
#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
Post by Ivan Maidanski
Post by Vitaly Magerya
#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.
Post by Ivan Maidanski
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)
Post by Ivan Maidanski
Post by Vitaly Magerya
Post by Ivan Maidanski
- looks like some thread is not unregistered (i.e. GC_remove_specific
not
Post by Ivan Maidanski
Post by Vitaly Magerya
Post by Ivan Maidanski
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.
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Petter Urkedal
2012-04-29 11:37:11 UTC
Permalink
HI Ivan,
Post by Ivan Maidanski
Sorry for the delay.
No problem.
Post by Ivan Maidanski
To my current understanding, the problem caused by missing GC_register_displacement(sizeof(oh)) (i.e. light "debugging_started") in GC_store_debug_info_inner. What do you think? (I guess I'll have some time to check your test case with such a fix tomorrow).
Indeed, there were missing calls to GC_start_debugging in
GC_debug_generic_malloc_inner in
GC_debug_generic_malloc_inner_ignore_off_page. I just copied the
pattern from the other allocation functions:
https://github.com/paurkedal/bdwgc/commits/fix-freelist-check-and-specific

It seems to work now on my end, including the disclaim_test.
Ivan Maidanski
2012-04-29 12:15:31 UTC
Permalink
Hi Petter,

But do we need the whole functionality of GC_start_debugging for it? (I guess it degrades performance when if you dont use GC_debug API routines.)

Regards.
Post by Petter Urkedal
HI Ivan,
Post by Ivan Maidanski
Sorry for the delay.
No problem.
Post by Ivan Maidanski
To my current understanding, the problem caused by missing GC_register_displacement(sizeof(oh)) (i.e. light "debugging_started") in GC_store_debug_info_inner. What do you think? (I guess I'll have some time to check your test case with such a fix tomorrow).
Indeed, there were missing calls to GC_start_debugging in
GC_debug_generic_malloc_inner in
GC_debug_generic_malloc_inner_ignore_off_page. I just copied the
https://github.com/paurkedal/bdwgc/commits/fix-freelist-check-and-specific
It seems to work now on my end, including the disclaim_test.
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Petter Urkedal
2012-04-29 15:26:19 UTC
Permalink
Post by Ivan Maidanski
Hi Petter,
But do we need the whole functionality of GC_start_debugging for it? (I guess it degrades performance when if you dont use GC_debug API routines.)
Hi Ivan,

I think we need to make these calls in all GC_debug_* functions in any
case, as they may be called by the client. But, I agree, these should
not be called unless the collector is being debugged. The expansion of
GC_INTERNAL_MALLOC in gc_priv.h redirects to the debug variants only
when DBG_HDRS_ALL is defined, which is the case when --gc-debug is
passed to configure, so this should be fine, right?

BTW, I updated the Ohloh (https://www.ohloh.net/p/bdwgc) repository
link. It still pointed to the CVS repo, so it started to look at bit
inactive.
Post by Ivan Maidanski
Regards.
Post by Petter Urkedal
HI Ivan,
Post by Ivan Maidanski
Sorry for the delay.
No problem.
Post by Ivan Maidanski
To my current understanding, the problem caused by missing GC_register_displacement(sizeof(oh)) (i.e. light "debugging_started") in GC_store_debug_info_inner. What do you think? (I guess I'll have some time to check your test case with such a fix tomorrow).
Indeed, there were missing calls to GC_start_debugging in
GC_debug_generic_malloc_inner in
GC_debug_generic_malloc_inner_ignore_off_page. I just copied the
https://github.com/paurkedal/bdwgc/commits/fix-freelist-check-and-specific
It seems to work now on my end, including the disclaim_test.
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Ivan Maidanski
2012-04-30 15:06:04 UTC
Permalink
Hi Petter,

I think you are right.

Regards.
Post by Petter Urkedal
Post by Ivan Maidanski
Hi Petter,
But do we need the whole functionality of GC_start_debugging for it? (I guess it degrades performance when if you dont use GC_debug API routines.)
Hi Ivan,
I think we need to make these calls in all GC_debug_* functions in any
case, as they may be called by the client. But, I agree, these should
not be called unless the collector is being debugged. The expansion of
GC_INTERNAL_MALLOC in gc_priv.h redirects to the debug variants only
when DBG_HDRS_ALL is defined, which is the case when --gc-debug is
passed to configure, so this should be fine, right?
BTW, I updated the Ohloh (https://www.ohloh.net/p/bdwgc) repository
link. It still pointed to the CVS repo, so it started to look at bit
inactive.
Post by Ivan Maidanski
Regards.
Post by Petter Urkedal
HI Ivan,
Post by Ivan Maidanski
Sorry for the delay.
No problem.
Post by Ivan Maidanski
To my current understanding, the problem caused by missing GC_register_displacement(sizeof(oh)) (i.e. light "debugging_started") in GC_store_debug_info_inner. What do you think? (I guess I'll have some time to check your test case with such a fix tomorrow).
Indeed, there were missing calls to GC_start_debugging in
GC_debug_generic_malloc_inner in
GC_debug_generic_malloc_inner_ignore_off_page. I just copied the
https://github.com/paurkedal/bdwgc/commits/fix-freelist-check-and-specific
It seems to work now on my end, including the disclaim_test.
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Ivan Maidanski
2012-04-29 14:36:17 UTC
Permalink
Hi Vitaly,

Based on your report:
1. There's a bug associated with enable-gc-debug - Petter already discovered the cause and te proper fix will be applied soon
2. If gc-debug is off then only stklos (not included into bdwgc) hangs regardless of USE_xxx_SPECIFIC, right?

I'll try to check stklos problem tomorrow.

Regards.
Post by Vitaly Magerya
Post by Ivan Maidanski
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,
all tests pass, stklos hangs on thread tests
all tests pass, stklos hangs on thread tests
disclaim_test segfaults (it passes on a very rare occasion)
#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
[...]
disclaim_test segfaults (sometimes)
all tests pass, stklos segfaults
"Assertion failure: thread_local_alloc.c:176".
#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 ...]
disclaim_test sometimes segfaults (rarely)
#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).
disclaim_test sometimes fails: "Assertion failure: dbg_mlc.c:843"
#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.
Post by Ivan Maidanski
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.
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Vitaly Magerya
2012-04-29 15:33:21 UTC
Permalink
Post by Ivan Maidanski
Hi Vitaly,
1. There's a bug associated with enable-gc-debug - Petter already discovered
the cause and te proper fix will be applied soon
Should I test his repo as it is, or wait until the fix hits your master branch?
Post by Ivan Maidanski
2. If gc-debug is off then only stklos (not included into bdwgc) hangs
regardless of USE_xxx_SPECIFIC, right?
Right, except that with USE_CUSTOM_SPECIFIC STklos hangs during
thread-related regression tests, but with USE_PTHREAD_SPECIFIC it
segfaults (inside GC_clear_fl_marks if I'm not mistaken) prior to
those.

There is a similar problem with Gauche, but I did not test it in
different configurations (I will once other problems are dealt with).
Post by Ivan Maidanski
I'll try to check stklos problem tomorrow.
Thank you.
Continue reading on narkive:
Loading...