Tom de Vries | 19 Jan 10:09 2015

[Gc] boehm-gc.c/gctest.c spurious failure


FYI, with gcc trunk on x86_64 Linux, I ran into PR64042: 'FAIL: 
boehm-gc.c/gctest.c -O2 execution test'. ( )

The testcase gctest fails spuriously, a couple of times per 1000 runs.

The failure has been reproduced by others, also on Darwin.

Any information on this is appreciated.

- Tom
Hans Aberg | 2 Jan 23:16 2015

[Gc] C++ global objects initialization

FYI: C++ global objects initialization on platforms where GC_INIT() is necessary, as on OS X 10.10, there
is the problem that the latter must be called before memory allocations by GC_malloc(). So it can’t be in main().

I found a workaround, that perhaps might be used to avoid GC_INIT() in the API (disregarding complications
with multiple allocators): the GC_malloc() replacement calls a pointer which first is an
initialization function, but is then changed to just the old GC_malloc().

In the code below, the GC_malloc() replacement is called gc_f. Then it seems to work in C++11 with the
operator new() replacements below, also with standard library containers global objects.

typedef void* (*malloc_ptr)(size_t);

extern malloc_ptr gc_f;

void* gc_uninitialized(size_t n) {
  gc_f = &GC_malloc;
  return gc_f(n);

malloc_ptr gc_f = gc_uninitialized;

void* operator new(std::size_t n) { return gc_f(n); }
void operator delete(void*) noexcept {}
void* operator new[](std::size_t n) { return gc_f(n); }
void operator delete[](void*) noexcept {}
bdwgc mailing list
(Continue reading)

John Leung | 29 Dec 22:58 2014

[Gc] cordtest, gctest FAIL on OSX

cordtest, gctest FAIL on OSX in make check

sys info:
OSX 10.9.2
Xcode 4.5.2
Please let me know what other information I need to provide.
thank you.

> make check
/Applications/  check-TESTS
./test-driver: line 107: 11117 Abort trap: 6           "$ <at> " > $log_file 2>&1
FAIL: cordtest
./test-driver: line 107: 11137 Abort trap: 6           "$ <at> " > $log_file 2>&1
FAIL: gctest
PASS: leaktest
PASS: middletest
PASS: smashtest
PASS: hugetest
PASS: realloc_test
PASS: staticrootstest
PASS: threadleaktest
PASS: threadkey_test
PASS: subthreadcreate_test
PASS: initsecondarythread_test
PASS: disclaim_test
PASS: disclaim_bench
make[5]: Nothing to be done for `all-am'.
Testsuite summary for gc 7.5.0
# TOTAL: 14
# PASS:  12
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0
See ./test-suite.log
Please report to bdwgc <at>
make[3]: *** [test-suite.log] Error 1
make[2]: *** [check-TESTS] Error 2
make[1]: *** [check-am] Error 2
make: *** [check-recursive] Error 1

> cat ./test-suite.log
   gc 7.5.0: ./test-suite.log

# TOTAL: 14
# PASS:  12
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: cordtest

FAIL: gctest

pthread_attr_setstacksize failed, error=22
Test failed

bdwgc mailing list
Niklas Therning | 22 Dec 08:41 2014

[Gc] iOS ARM64 (Aarch64) support


We've made a first attempt [1] at porting the GC to iOS ARM64
(Aarch64) and so far it seems to be working fine. Wanted to check
whether someone else is working on this as well?

One initial problem we had was what we'd set STACKBOTTOM to. The value
for iOS 32-bit seemed totally arbitrary. But AFAICS, for Darwin, the
actual value for STACKBOTTOM is ignored and instead it's set to the
expression (ptr_t)pthread_get_stackaddr_np(pthread_self()) in
os_dep.c. Can someone please confirm that this is indeed what happens
for OS X/iOS?

Please let me know whether you'd be interested in merging this and
I'll send a PR.


Hans Aberg | 30 Nov 23:44 2014

[Gc] OS X 10.10 install

I get, on OS X 10.10.1, a ./configure error [1] with gc-7.4.2: it can’t find libatomic_ops-7.4.2, which I
have installed on the system, nor does linking help.

1. ./configure
checking for dladdr... yes
checking sys/dg_sys_info.h usability... no
checking sys/dg_sys_info.h presence... no
checking for sys/dg_sys_info.h... no
checking for pkg-config... no
checking for ATOMIC_OPS... no
configure: error: libatomic_ops is required.  You can either install it on
                  your system, or fetch and unpack a recent version into the
                  source directory and link or rename it to libatomic_ops.
bdwgc mailing list
bdwgc <at>
Jean-Claude Beaudoin | 19 Nov 02:23 2014

[Gc] On Linux, BDWGC prefers sbrk() over mmap(), why is that so?

Hello BDWGC folks,

During a recent bug chase of mine I stumbled over the fact that, in its default configuration on Linux, this GC will always try to call sbrk() before falling back onto mmap() (see GC_unix_get_mem() et al. in os_dep.c).

This is despite the fact that I configure my copy with --enable-threads=posix.
My system operates in a context where there is a number of threads not under GC control along with the set of threads the GC do control. On Linux, brk()/sbrk() is NOT a thread-safe facility and calls to it from non-GC threads or from other application code (dlopen() is liberally used in this system) cannot be prevented.

Further more, non-GC threads are very likely to use malloc() et al. for their memory needs, and malloc() relies on brk()/sbrk() for (at least a good part of) its business. A clash of some sort between malloc and BDWGC on their respective use of brk()/sbrk() seems in my opinion to be very likely, is it not?

The use of mmap() alone (no brk()/sbrk()) seems to be hardcoded in include/private/gcconfig.h for a number of platform (IRIX, AIX, Solaris, etc) but not for Linux. Is there some fundamental reason for this?

BTW, access to the use of mmap() through the "configure" interface seem to have been intentionally removed at some point in the past. One needs to edit in order to use the remnants of it.


Jean-Claude Beaudoin

bdwgc mailing list
Rodrigo Kumpera | 8 Nov 18:16 2014

[Gc] STW usage of signals

Hey Guys,

The mono VM is running short of usable signals on some targets and we're going to do signal multiplexing.

We use the same signal based suspend/resume mechanism as bdwgc and I've been wondering on why sigwait was used instead of a semaphore to implement resume.

This decision was made way way in the past but maybe someone still remember the rationale for it?


bdwgc mailing list
Thomas Klausner | 27 Oct 16:12 2014

[Gc] gc, guile, and NetBSD


I'm trying to get a usable guile-2.0.11 on NetBSD-7.99.1/x86_64.
guile-1.8.x works fine on the same system.

I'm using gc-7.4.2 from pkgsrc, which currently has no additional
patches. It is compiled with --enable-cplusplus and --disable-threads.
'make check' passes without errors.

The guile build fails with:

  GEN      guile-procedures.texi
GC_is_visible test failed
[1]   Broken pipe             cat alist.doc ar... |
      Abort trap (core dumped) GUILE_INSTALL_LO...

which is the first time that the linked guile binary is actually

The backtrace looks like this:
Core was generated by `guile'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007f7ff4d0e2ca in _lwp_kill () from /usr/lib/
(gdb) bt
#0  0x00007f7ff4d0e2ca in _lwp_kill () from /usr/lib/
#1  0x00007f7ff4d0df55 in abort () at /archive/foreign/src/lib/libc/stdlib/abort.c:74
#2  0x00007f7ff7415d2b in GC_default_is_visible_print_proc () from /usr/obj/wip/guile2/work/.buildlink/lib/
#3  0x00007f7ff7416031 in GC_is_visible () from /usr/obj/wip/guile2/work/.buildlink/lib/
#4  0x00007f7ff786d479 in scm_storage_prehistory () from /usr/obj/wip/guile2/work/guile-2.0.11/libguile/.libs/
#5  0x00007f7ff787bc7a in scm_i_init_guile () from /usr/obj/wip/guile2/work/guile-2.0.11/libguile/.libs/
#6  0x00007f7ff78c9b6a in scm_i_init_thread_for_guile () from /usr/obj/wip/guile2/work/guile-2.0.11/libguile/.libs/
#7  0x00007f7ff78c9b89 in with_guile_and_parent () from /usr/obj/wip/guile2/work/guile-2.0.11/libguile/.libs/
#8  0x00007f7ff7414ca9 in GC_call_with_stack_base () from /usr/obj/wip/guile2/work/.buildlink/lib/
#9  0x00007f7ff78ca0af in scm_with_guile () from /usr/obj/wip/guile2/work/guile-2.0.11/libguile/.libs/
#10 0x00007f7ff787bc3c in scm_boot_guile () from /usr/obj/wip/guile2/work/guile-2.0.11/libguile/.libs/
#11 0x000000000040104d in main ()

The code that is running at that point is at;a=blob;f=libguile/gc.c;h=13823c054cb0d08cbaf1ced5209c41d9857b8bd4;hb=HEAD#l623

I've talked with some guile developers on IRC, and they claim that
they are just using gc like intended, and that this is a problem in gc
on NetBSD, not in guile.

I'm out of my depth here, and hope that someone on this list has an
insight in what might be going wrong here and how to fix it.

Ivan Maidanski | 27 Oct 07:47 2014

Re: [Gc] Cannot make cord/tests/{cordtest,de}


It depends - both are used:
#include <gc/cord.h> // it is assumed gc is installed

#include "cord.h" // you should specify -I option but no need to install gc


Thursday, 23 Oct 2014, 12:15 +03:00 from 张睿 <zrui16 <at>>:


The point is that gc header files are installed into $(prefix)/include/gc. When I build my own programs, the compiler will not find them unless I specify -I$(prefix)/include/gc to it.

I would like to ask which of the two is preferred: 1) specify the include path when compiling; 2) write #include<gc/cord.h> instead of #include <cord.h> in the source so that I do not have to specify the include path explicitly.​ (The compiler does search $(prefix)/include for headers.)

“make test” works fine since it is working in the source directory, where everything is present.

发件人:   Ivan Maidanski
发送时间:  ‎2014‎年‎10‎月‎23‎日, ‎星期四 ‎16‎:‎30
收件人:   张睿
抄送:   bdwgc <at>


I fixed second issue -
About 1st one, I don't completely understand it. "./configure && make test" compiles and executes cordtest.


Wed, 8 Oct 2014 16:00:29 +0000 from 张睿 <zrui16 <at>>:
>After ./configure and make && make install, I have only a gc.h under $(prefix)/include/, and the following files under $(prefix)/include/gc/ directory:
>cord.h  gc_allocator.h  gc_config_macros.h  gc_gcj.h     gc_mark.h               gc_tiny_fl.h  gc_version.h  leak_detector.h
>gc.h    gc_backptr.h    gc_disclaim.h       gc_inline.h  gc_pthread_redirects.h  gc_typed.h    javaxfc.h     weakpointer.h
>There are two reasons that I cannot make cord/tests/{cordtest,de}.
>First, cordtest.c and de.c include cord.h, which is not present in $(prefix)/include/ but $(prefix)/include/gc instead. The latter is not in gcc's search directories.
>Second, cord_pos.h is not installed, but cord.h includes this file.
>A quick fix for me is to copy cord_pos.h to $(prefix)/gc/ manually and replace #include "cord.h" with #include "gc/cord.h".
>It seems to me that the building script needs to be updated for cord-related stuff. I have looked into the documentation (doc/README.cords) but I didn't find anything useful.
>bdwgc mailing list
>bdwgc <at>

bdwgc mailing list
Ivan Maidanski | 25 Oct 19:29 2014

[Gc] Fwd: Re: AArch64: Shareability domain for dmb st overly conservative (#11)

Forwarding to ML..

From: Ivan Maidanski <ivmai <at>>
To: Yvan Roux <yvan.roux <at>>, Hans Boehm <boehm <at>>
CC: ivmai/libatomic_ops <libatomic_ops <at>>, ivmai/libatomic_ops <reply+i-46004519-50324839f75648d459559128d780ac126d37fdde-460469 <at>>, Boehm GC <bdwgc <at>>
Date: Thu, 23 Oct 2014 12:36:39 +0400
Subject: Re: [libatomic_ops] AArch64: Shareability domain for dmb st overly conservative (#11)

Hi Yvan and Hans,

Is the proposed change correct for ARM64 AO_nop_write? What's about 32-bit ARM?

Thank you

Thu, 16 Oct 2014 09:08:26 -0700 from stevecapperlinaro <notifications <at>>:

In src/atomic_ops/sysdeps/gcc/aarch64.h, we have the following code:
__asm__ __volatile__("dmb st" : : : "memory");

This will target the system domain and thus be overly conservative as the CPUs will occupy the inner shareable domain.

Could this please be changed to:
__asm__ __volatile__("dmb ishst" : : : "memory");

That way the barriers will occupy the inner shareable domain.

Steve Capper

bdwgc mailing list
Colin Gordon | 14 Oct 20:27 2014

[Gc] Compiling bdwgc via emscripten


I’ve been trying to compile bdwgc with the Emscripten support recently upstreamed from Unity.  But I cannot figure out how to produce a working build.  From glancing at the relevant changes on github, and following Emscripten’s build integration instructions, I’ve tried essentially using:

emconfigure ./configure —prefix=.../gcout/ --without-threads --disable-threads __EMSCRIPTEN__=1 EMSCRIPTEN=1

I’ve tried with and without explicitly setting CC, CXX, etc.  This produces a shared library file containing LLVM bit code, which when disassembled appears to contain the relevant GC symbols and the expected target triple “asmjs-unknown-emscripten.”  But linking against this result fails with emscripten searching for intermediate JavaScript files that do not exist.  “make check” (and “emmake make check”) fail all tests.  Are there any docs on the emscripten support?  I haven’t been able to locate any.  Can anyone suggest what I might be missing or doing incorrectly?

If relevant, I’m using the Emscripten portable SDK on Mac OS X.

bdwgc mailing list