ivmai / bdwgc

The Boehm-Demers-Weiser conservative C/C++ Garbage Collector (bdwgc, also known as bdw-gc, boehm-gc, libgc)

Boehm-Demers-Weiser Garbage Collector

This is version 8.3.0 (next release development) of a conservative garbage collector for C and C++.

License: MIT-style

Download

You might find a more recent/stable version on the Download page, or BDWGC site.

Also, the latest bug fixes and new features are available in the development repository.

Overview

This is intended to be a general purpose, garbage collecting storage allocator. The algorithms used are described in:

• Boehm, H., and M. Weiser, "Garbage Collection in an Uncooperative Environment", Software Practice & Experience, September 1988, pp. 807-820.

• Boehm, H., A. Demers, and S. Shenker, "Mostly Parallel Garbage Collection", Proceedings of the ACM SIGPLAN '91 Conference on Programming Language Design and Implementation, SIGPLAN Notices 26, 6 (June 1991), pp. 157-164.

• Boehm, H., "Space Efficient Conservative Garbage Collection", Proceedings of the ACM SIGPLAN '91 Conference on Programming Language Design and Implementation, SIGPLAN Notices 28, 6 (June 1993), pp. 197-206.

• Boehm H., "Reducing Garbage Collector Cache Misses", Proceedings of the 2000 International Symposium on Memory Management.

Possible interactions between the collector and optimizing compilers are discussed in

• Boehm, H., and D. Chase, "A Proposal for GC-safe C Compilation", The Journal of C Language Translation 4, 2 (December 1992).

• Boehm H., "Simple GC-safe Compilation", Proceedings of the ACM SIGPLAN '96 Conference on Programming Language Design and Implementation.

Unlike the collector described in the second reference, this collector operates either with the mutator stopped during the entire collection (default) or incrementally during allocations. (The latter is supported on fewer machines.) On the most common platforms, it can be built with or without thread support. On some platforms, it can take advantage of a multiprocessor to speed up garbage collection.

Many of the ideas underlying the collector have previously been explored by others. Notably, some of the run-time systems developed at Xerox PARC in the early 1980s conservatively scanned thread stacks to locate possible pointers (cf. Paul Rovner, "On Adding Garbage Collection and Runtime Types to a Strongly-Typed Statically Checked, Concurrent Language" Xerox PARC CSL 84-7). Doug McIlroy wrote a simpler fully conservative collector that was part of version 8 UNIX (tm), but appears to not have received widespread use.

Rudimentary tools for use of the collector as a leak detector are included, as is a fairly sophisticated string package "cord" that makes use of the collector. (See README.cords and H.-J. Boehm, R. Atkinson, and M. Plass, "Ropes: An Alternative to Strings", Software Practice and Experience 25, 12 (December 1995), pp. 1315-1330. This is very similar to the "rope" package in Xerox Cedar, or the "rope" package in the SGI STL or the g++ distribution.)

Further collector documentation can be found in the overview.

Some of the known uses of the collector are listed on the GitHub Known-clients page.

General Description

This is a garbage collecting storage allocator that is intended to be used as a plug-in replacement for C's malloc.

Since the collector does not require pointers to be tagged, it does not attempt to ensure that all inaccessible storage is reclaimed. However, in our experience, it is typically more successful at reclaiming unused memory than most C programs using explicit deallocation. Unlike manually introduced leaks, the amount of unreclaimed memory typically stays bounded.

In the following, an "object" is defined to be a region of memory allocated by the routines described below.

Any objects not intended to be collected must be pointed to either from other such accessible objects, or from the registers, stack, data, or statically allocated bss segments. Pointers from the stack or registers may point to anywhere inside an object. The same is true for heap pointers if the collector is compiled with ALL_INTERIOR_POINTERS defined, or GC_all_interior_pointers is otherwise set, as is now the default.

Compiling without ALL_INTERIOR_POINTERS may reduce accidental retention of garbage objects, by requiring pointers from the heap to the beginning of an object. But this no longer appears to be a significant issue for most programs occupying a small fraction of the possible address space.

There are a number of routines which modify the pointer recognition algorithm. GC_register_displacement allows certain interior pointers to be recognized even if ALL_INTERIOR_POINTERS is not defined. GC_malloc_ignore_off_page allows some pointers into the middle of large objects to be disregarded, greatly reducing the probability of accidental retention of large objects. For most purposes it seems best to compile with ALL_INTERIOR_POINTERS and to use GC_malloc_ignore_off_page if you get collector warnings from allocations of very large objects. See here for details.

WARNING: pointers inside memory allocated by the standard (system) malloc are not seen by the garbage collector. Thus objects pointed to only from such a region may be prematurely deallocated. It is thus suggested that the standard malloc be used only for memory regions, such as I/O buffers, that are guaranteed not to contain pointers to garbage collectible memory. Pointers in C language automatic, static, or register variables, are correctly recognized. (Note that GC_malloc_uncollectable has semantics similar to standard malloc, but allocates objects that are traced by the collector.)

WARNING: the collector does not always know how to find pointers in data areas that are associated with dynamic libraries. This is easy to remedy if you know how to find those data areas on your operating system (see GC_add_roots). Code for doing this under SunOS, IRIX 5.X and 6.X, HP/UX, Alpha OSF/1, Linux, and Win32 is included and used by default. (See README.win32 and README.win64 for Windows details.) On other systems, pointers from dynamic library data areas may not be considered by the collector. If you're writing a program that depends on the collector scanning dynamic library data areas, it may be a good idea to include at least one call to GC_is_visible to ensure that those areas are visible to the collector.

Note that the garbage collector does not need to be informed of shared read-only data. However, if the shared library mechanism can introduce discontiguous data areas that may contain pointers then the collector does need to be informed.

Signal processing for most signals may be deferred during collection, and during uninterruptible parts of the allocation process. Like standard ANSI C mallocs, by default it is unsafe to invoke malloc (and other GC routines) from a signal handler while another malloc call may be in progress.

The allocator/collector can also be configured for thread-safe operation. (Full signal safety can also be achieved, but only at the cost of two system calls per malloc, which is usually unacceptable.)

WARNING: the collector does not guarantee to scan thread-local storage (e.g. of the kind accessed with pthread_getspecific). The collector does scan thread stacks, though, so generally the best solution is to ensure that any pointers stored in thread-local storage are also stored on the thread's stack for the duration of their lifetime. (This is arguably a longstanding bug, but it hasn't been fixed yet.)

Building and Installing

There are multiple ways to build the collector:

• CMake (it is the recommended way)
• GNU autoconf/automake
• Zig (experimental)
• MS nmake (directly)
• Makefile.direct
• Manual C compilation

CMake

The simplest way to build libgc (as well as libcord) and run the tests using cmake:

mkdir out
cd out
cmake -Dbuild_tests=ON ..
cmake --build .
ctest

This is the most cross-platform way of building the library. See README.cmake for details.

GNU Autoconf/Automake

Please note that the collector source repository does not contain configure and similar auto-generated files, thus the full procedure of autoconf-based build of the collector from the source repository could look like:

./autogen.sh
./configure
make check

The GNU style build process understands the usual targets and options. make install installs libgc and libcord. Try ./configure --help to see all the configuration options. It is currently not possible to exercise all combinations of build options this way.

See README.autoconf for details.

Zig

Building and testing the collector using zig is straight forward in its simplest form:

zig build test

It is possible to configure the build through the use of variables, e.g. zig build -Denable_redirect_malloc -Denable_threads=false. Zig offers excellent cross-compilation functionality, it is configurable like this:

zig build -Dtarget=riscv64-linux-musl

Currently, a nightly version of zig 0.12 is required, which can be downloaded from https://ziglang.org/download/

MS nmake

On Windows, assuming the Microsoft build tools are installed and suitably configured, it is possible to build the library and run the tests using nmake directly, e.g. by by typing nmake -f NT_MAKEFILE check. However, the recommended way is to use cmake as described above.

See README.win32 for details.

Makefile.direct

For the old-style (classic) makefile-based build process, typing make -f Makefile.direct check will automatically build libgc, libcord and then run a number of tests such as gctest. The test is a somewhat superficial test of collector functionality. Failure is indicated by a core dump or a message to the effect that the collector is broken. gctest may take a dozen of seconds to run on reasonable 2023 vintage 64-bit desktops. It may use up to about 30 MB of memory.

Makefile.direct will generate a library libgc.a which you should link against.

Manual C Compilation

Finally, on most targets, the collector could be built and tested directly with a single compiler invocation, like this (the sample lacks multi-threading support):

cc -I include -o gctest tests/gctest.c extra/gc.c && ./gctest

E.g., this could be convenient for a debugging purpose.

Configurable Macros

The library can be configured more precisely during the build by defining the macros listed in README.macros file.

The library is built with threads support enabled (i.e. for thread-safe operation) by default, unless explicitly disabled by:

• -Denable_threads=false option passed to cmake or zig build
• --disable-threads option passed to ./configure

The collector operates silently in the default configuration. In the event of issues, this can usually be changed by defining the GC_PRINT_STATS or GC_PRINT_VERBOSE_STATS environment variables. This will result in a few lines of descriptive output for each collection. (The given statistics exhibit a few peculiarities. Things don't appear to add up for a variety of reasons, most notably fragmentation losses. These are probably much more significant for the contrived program gctest than for your application.)

Atomic ops

Use (cloning) of libatomic_ops is now optional provided the compiler supports atomic intrinsics. Most modern compilers do. The notable exception is the MS compiler (as of Visual Studio 2022).

If needed, most OS distributes have libatomic_ops package; alternatively, you can download or clone it from https://github.com/ivmai/libatomic_ops space.

Portability

The collector currently is designed to run essentially unmodified on machines that use a flat 32-bit or 64-bit address space. That includes the vast majority of Workstations and x86 (i386 or later) PCs.

In a few cases (e.g., OS/2, Win32) a separate makefile is supplied; these have a separate host-specific docs/platforms/README.* file.

Dynamic libraries are completely supported only under SunOS/Solaris, (and even that support is not functional on the last Sun 3 release), Linux, FreeBSD, NetBSD, IRIX, HP/UX, Win32 (not win32s) and OSF/1 on DEC AXP machines plus perhaps a few others listed near the top of dyn_load.c. On other machines we recommend that you do one of the following:

1. Add dynamic library support (and send us the code).
2. Use static versions of the libraries.
3. Arrange for dynamic libraries to use the standard malloc. This is still dangerous if the library stores a pointer to a garbage collected object. But nearly all standard interfaces prohibit this, because they deal correctly with pointers to stack allocated objects. (strtok is an exception. Don't use it.)

In all cases we assume that pointer alignment is consistent with that enforced by the standard C compilers. If you use a nonstandard compiler you may have to adjust the alignment parameters defined in include/private/gc_priv.h. Note that this may also be an issue with packed records/structs, if those enforce less alignment for pointers.

A port to a machine that is not byte addressed, or does not use 32 bit or 64 bit addresses will require a major effort. A port to plain MSDOS or win16 is hard.

For machines not already mentioned, or for nonstandard compilers, some porting suggestions are provided here.

The C Interface to the Allocator

The following routines are intended to be directly called by the user. Note that usually only GC_malloc is necessary. GC_clear_roots and GC_add_roots calls may be required if the collector has to trace from nonstandard places (e.g. from dynamic library data areas on a machine on which the collector doesn't already understand them.) On some machines, it may be desirable to set GC_stackbottom to a good approximation of the stack base (bottom).

Client code may include gc.h, which defines all of the following, plus many others.

1. GC_malloc(bytes) - Allocate an object of a given size. Unlike malloc, the object is cleared before being returned to the user. GC_malloc will invoke the garbage collector when it determines this to be appropriate. GC_malloc may return 0 if it is unable to acquire sufficient space from the operating system. This is the most probable consequence of running out of space. Other possible consequences are that a function call will fail due to lack of stack space, or that the collector will fail in other ways because it cannot maintain its internal data structures, or that a crucial system process will fail and take down the machine. Most of these possibilities are independent of the malloc implementation.

2. GC_malloc_atomic(bytes) - Allocate an object of a given size that is guaranteed not to contain any pointers. The returned object is not guaranteed to be cleared. (Can always be replaced by GC_malloc, but results in faster collection times. The collector will probably run faster if large character arrays, etc. are allocated with GC_malloc_atomic than if they are statically allocated.)

3. GC_realloc(object, new_bytes) - Change the size of object to be of a given size. Returns a pointer to the new object, which may, or may not, be the same as the pointer to the old object. The new object is taken to be atomic if and only if the old one was. If the new object is composite and larger than the original object then the newly added bytes are cleared. This is very likely to allocate a new object.

4. GC_free(object) - Explicitly deallocate an object returned by GC_malloc or GC_malloc_atomic, or friends. Not necessary, but can be used to minimize collections if performance is critical. Probably a performance loss for very small objects (<= 8 bytes).

5. GC_expand_hp(bytes) - Explicitly increase the heap size. (This is normally done automatically if a garbage collection failed to reclaim enough memory. Explicit calls to GC_expand_hp may prevent unnecessarily frequent collections at program startup.)

6. GC_malloc_ignore_off_page(bytes) - Identical to GC_malloc, but the client promises to keep a pointer to the somewhere within the first GC heap block (512 .. 4096 bytes or even more, depending on the configuration) of the object while it is live. (This pointer should normally be declared volatile to prevent interference from compiler optimizations.) This is the recommended way to allocate anything that is likely to be larger than 100 KB or so. (GC_malloc may result in a failure to reclaim such objects.)

7. GC_set_warn_proc(proc) - Can be used to redirect warnings from the collector. Such warnings should be rare, and should not be ignored during code development.

8. GC_enable_incremental() - Enables generational and incremental collection. Useful for large heaps on machines that provide access to page dirty information. Some dirty bit implementations may interfere with debugging (by catching address faults) and place restrictions on heap arguments to system calls (since write faults inside a system call may not be handled well).

9. GC_register_finalizer(object, proc, data, 0, 0) and friends - Allow for registration of finalization code. User supplied finalization code ((*proc)(object, data)) is invoked after object becomes unreachable. For more sophisticated uses, and for finalization ordering issues, see gc.h.

The global variable GC_free_space_divisor may be adjusted up from it default value of 3 to use less space and more collection time, or down for the opposite effect. Setting it to 1 will almost disable collections and cause all allocations to simply grow the heap.

The variable GC_non_gc_bytes, which is normally 0, may be changed to reflect the amount of memory allocated by the above routines that should not be considered as a candidate for collection. Careless use may, of course, result in excessive memory consumption.

Some additional tuning is possible through the parameters defined near the top of include/private/gc_priv.h.

If only GC_malloc is intended to be used, it might be appropriate to define:

#define malloc(n) GC_malloc(n)
#define calloc(m,n) GC_malloc((m)*(n))

For small pieces of VERY allocation intensive code, gc_inline.h includes some allocation macros that may be used in place of GC_malloc and friends.

All externally visible names in the garbage collector start with GC_. To avoid name conflicts, client code should avoid this prefix, except when accessing garbage collector routines.

There are provisions for allocation with explicit type information. This is rarely necessary. Details can be found in gc_typed.h.

The C++ Interface to the Allocator

The Ellis-Hull C++ interface to the collector is included in the collector distribution. If you intend to use this, type ./configure --enable-cplusplus && make (or cmake -Denable_cplusplus=ON . && cmake --build ., or make -f Makefile.direct c++ depending on the build system you use). This creates libgccpp.a and libgctba.a files, or their shared library equivalents (libgccpp.so and libgctba.so). You should link with either the first (gccpp) or the second one (gctba), but not both. See gc_cpp.h and here for the definition of the interface. This interface tries to approximate the Ellis-Detlefs C++ garbage collection proposal without compiler changes.

Very often it will also be necessary to use gc_allocator.h and the allocator declared there to construct STL data structures. Otherwise subobjects of STL data structures will be allocated using a system allocator, and objects they refer to may be prematurely collected.

Use as Leak Detector

The collector may be used to track down leaks in C programs that are intended to run with malloc/free (e.g. code with extreme real-time or portability constraints). To do so define FIND_LEAK in Makefile. This will cause the collector to print a human-readable object description whenever an inaccessible object is found that has not been explicitly freed. Such objects will also be automatically reclaimed.

If all objects are allocated with GC_DEBUG_MALLOC (see the next section) then, by default, the human-readable object description will at least contain the source file and the line number at which the leaked object was allocated. This may sometimes be sufficient. (On a few machines, it will also report a cryptic stack trace. If this is not symbolic, it can sometimes be called into a symbolic stack trace by invoking program "foo" with tools/callprocs.sh foo. It is a short shell script that invokes adb to expand program counter values to symbolic addresses. It was largely supplied by Scott Schwartz.)

Note that the debugging facilities described in the next section can sometimes be slightly LESS effective in leak finding mode, since in the latter GC_debug_free actually results in reuse of the object. (Otherwise the object is simply marked invalid.) Also, note that most GC tests are not designed to run meaningfully in FIND_LEAK mode.

Debugging Facilities

The routines GC_debug_malloc, GC_debug_malloc_atomic, GC_debug_realloc, and GC_debug_free provide an alternate interface to the collector, which provides some help with memory overwrite errors, and the like. Objects allocated in this way are annotated with additional information. Some of this information is checked during garbage collections, and detected inconsistencies are reported to stderr.

Simple cases of writing past the end of an allocated object should be caught if the object is explicitly deallocated, or if the collector is invoked while the object is live. The first deallocation of an object will clear the debugging info associated with an object, so accidentally repeated calls to GC_debug_free will report the deallocation of an object without debugging information. Out of memory errors will be reported to stderr, in addition to returning NULL.

GC_debug_malloc checking during garbage collection is enabled with the first call to this function. This will result in some slowdown during collections. If frequent heap checks are desired, this can be achieved by explicitly invoking GC_gcollect, e.g. from the debugger.

GC_debug_malloc allocated objects should not be passed to GC_realloc or GC_free, and conversely. It is however acceptable to allocate only some objects with GC_debug_malloc, and to use GC_malloc for other objects, provided the two pools are kept distinct. In this case, there is a very low probability that GC_malloc allocated objects may be misidentified as having been overwritten. This should happen with probability at most one in 2**32. This probability is zero if GC_debug_malloc is never called.

GC_debug_malloc, GC_debug_malloc_atomic, and GC_debug_realloc take two additional trailing arguments, a string and an integer. These are not interpreted by the allocator. They are stored in the object (the string is not copied). If an error involving the object is detected, they are printed.

The macros GC_MALLOC, GC_MALLOC_ATOMIC, GC_REALLOC, GC_FREE, GC_REGISTER_FINALIZER and friends are also provided. These require the same arguments as the corresponding (nondebugging) routines. If gc.h is included with GC_DEBUG defined, they call the debugging versions of these functions, passing the current file name and line number as the two extra arguments, where appropriate. If gc.h is included without GC_DEBUG defined then all these macros will instead be defined to their nondebugging equivalents. (GC_REGISTER_FINALIZER is necessary, since pointers to objects with debugging information are really pointers to a displacement of 16 bytes from the object beginning, and some translation is necessary when finalization routines are invoked. For details, about what's stored in the header, see the definition of the type oh in dbg_mlc.c file.)

Incremental/Generational Collection

The collector normally interrupts client code for the duration of a garbage collection mark phase. This may be unacceptable if interactive response is needed for programs with large heaps. The collector can also run in a "generational" mode, in which it usually attempts to collect only objects allocated since the last garbage collection. Furthermore, in this mode, garbage collections run mostly incrementally, with a small amount of work performed in response to each of a large number of GC_malloc requests.

This mode is enabled by a call to GC_enable_incremental.

Incremental and generational collection is effective in reducing pause times only if the collector has some way to tell which objects or pages have been recently modified. The collector uses two sources of information:

1. Information provided by the VM system. This may be provided in one of several forms. Under Solaris 2.X (and potentially under other similar systems) information on dirty pages can be read from the /proc file system. Under other systems (e.g. SunOS4.X) it is possible to write-protect the heap, and catch the resulting faults. On these systems we require that system calls writing to the heap (other than read) be handled specially by client code. See os_dep.c for details.

2. Information supplied by the programmer. The object is considered dirty after a call to GC_end_stubborn_change provided the library has been compiled suitably. It is typically not worth using for short-lived objects. Note that bugs caused by a missing GC_end_stubborn_change or GC_reachable_here call are likely to be observed very infrequently and hard to trace.

Bugs

Any memory that does not have a recognizable pointer to it will be reclaimed. Exclusive-or'ing forward and backward links in a list doesn't cut it.

Some C optimizers may lose the last undisguised pointer to a memory object as a consequence of clever optimizations. This has almost never been observed in practice.

This is not a real-time collector. In the standard configuration, percentage of time required for collection should be constant across heap sizes. But collection pauses will increase for larger heaps. They will decrease with the number of processors if parallel marking is enabled.

(On 2007 vintage machines, GC times may be on the order of 5 ms per MB of accessible memory that needs to be scanned and processed. Your mileage may vary.) The incremental/generational collection facility may help in some cases.

Feedback, Contribution, Questions and Notifications

Please address bug reports and new feature ideas to GitHub issues. Before the submission please check that it has not been done yet by someone else.

If you want to contribute, submit a pull request to GitHub.

If you need help, use Stack Overflow. Older technical discussions are available in bdwgc mailing list archive - it can be downloaded as a compressed file or browsed at Narkive.

To get new release announcements, subscribe to RSS feed. (To receive the notifications by email, a 3rd-party free service like IFTTT RSS Feed can be setup.) To be notified on all issues, please watch the project on GitHub.

Copyright & Warranty, Contributors

Our intent is to make it easy to use bdwgc (libgc), in both free and proprietary software. Hence, the Boehm-Demers-Weiser conservative garbage collector code that we expect to be linked dynamically or statically into a client application is covered by own license, which is similar in spirit to an MIT-style one.

The exact licensing information is provided in LICENSE file.

All the contributors are listed in AUTHORS file.

bdwgc's Issues

Crash on Android/arm if GC is a dynamic library

Crash can be reproduced even on a simple console app which does GC_INIT + GC_malloc, GC is single-threaded. GC as a static library is ok. I haven't investigated the reason yet.

Target: android 6.x arm32
Source code: GC from master branch, libatomic_ops not used.

"Stable" Version 7.2f Fails to Build on openSUSE Linux

gc-7.2f.tar.gz

ts2@linux-0fiz:~/m_local/bin_p/Sage/kompileerimine$ rm -fr ./gc-7.2
ts2@linux-0fiz:~/m_local/bin_p/Sage/kompileerimine$ sha256sum ./gc-7.2f.tar 
84b346c7399ac18be4d7dabc350038d608d447e94fc88a6208d23929f333acce  ./gc-7.2f.tar
ts2@linux-0fiz:~/m_local/bin_p/Sage/kompileerimine$ tar -xf ./gc-7.2f.tar 
ts2@linux-0fiz:~/m_local/bin_p/Sage/kompileerimine$ cd gc-7.2/
ts2@linux-0fiz:~/m_local/bin_p/Sage/kompileerimine/gc-7.2$ ls
aclocal.m4                  dbg_mlc.c                  Makefile.am                     PCR-Makefile
allchblk.c                  depcomp                    Makefile.direct                 pthread_start.c
alloc.c                     digimars.mak               Makefile.dj                     pthread_stop_world.c
alpha_mach_dep.S            doc                        Makefile.DLLs                   pthread_support.c
autogen.sh                  dyn_load.c                 Makefile.in                     ptr_chck.c
backgraph.c                 EMX_MAKEFILE               malloc.c                        README.QUICK
BCC_MAKEFILE                extra                      mallocx.c                       real_malloc.c
bdw-gc.pc.in                finalize.c                 mark.c                          reclaim.c
blacklst.c                  gc_cpp.cc                  mark_rts.c                      rs6000_mach_dep.s
build_atomic_ops.sh         gc_cpp.cpp                 mips_sgi_mach_dep.s             SMakefile.amiga
build_atomic_ops.sh.cygwin  gc_dlopen.c                mips_ultrix_mach_dep.s          sparc_mach_dep.S
callprocs                   gcj_mlc.c                  misc.c                          sparc_netbsd_mach_dep.s
ChangeLog                   gc.mak                     missing                         sparc_sunos4_mach_dep.s
checksums.c                 headers.c                  mkinstalldirs                   specific.c
CMakeLists.txt              ia64_save_regs_in_stack.s  new_hblk.c                      stubborn.c
compile                     include                    NT_MAKEFILE                     test-driver
config.guess                install-sh                 NT_STATIC_THREADS_MAKEFILE      tests
config.sub                  libatomic_ops              NT_X64_STATIC_THREADS_MAKEFILE  thread_local_alloc.c
configure                   ltmain.sh                  NT_X64_THREADS_MAKEFILE         typd_mlc.c
configure.ac                m4                         obj_map.c                       WCC_MAKEFILE
configure.host              Mac_files                  OS2_MAKEFILE                    win32_threads.c
cord                        mach_dep.c                 os_dep.c
darwin_stop_world.c         MacProjects.sit.hqx        pcr_interface.c
ts2@linux-0fiz:~/m_local/bin_p/Sage/kompileerimine/gc-7.2$ ./autogen.sh 
+ aclocal
+ autoconf
+ autoheader
+ automake -ac
+ libtoolize --automake --force
+ set +x

Ready to run './configure'.

ts2@linux-0fiz:~/m_local/bin_p/Sage/kompileerimine/gc-7.2$ ./configure --prefix=/home/ts2/m_local/bin_p/Sage/paigaldatult/boehm_demers_weiser_garbage_collector --with-gnu-ld --enable-cplusplus --enable-large-config --enable-handle-fork 
configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking GC version numbers... major=7 minor=2 
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking whether gcc and cc understand -c and -o together... yes
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking dependency style of gcc... gcc3
checking for thread model used by GCC... posix
checking for inline... inline
checking for pthread_self in -lpthread... yes
configure: WARNING: "Explicit GC_INIT() calls may be required."
checking for xlc... no
checking whether gcc supports -fno-strict-aliasing... yes
checking for dlopen in -ldl... yes
checking whether to build shared libraries... yes
checking which machine-dependent code should be used... 
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/x86_64-suse-linux/bin/ld
checking if the linker (/usr/x86_64-suse-linux/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/x86_64-suse-linux/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/x86_64-suse-linux/bin/ld -m elf_x86_64
checking if the linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether Solaris gcc optimization fix is necessary... no
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... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for ATOMIC_OPS... no
checking which libatomic_ops to use... internal
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating bdw-gc.pc
config.status: creating include/private/config.h
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing default commands
=== configuring in libatomic_ops (/home/ts2/m_local/bin_p/Sage/kompileerimine/gc-7.2/libatomic_ops)
configure: running /bin/sh ./configure --disable-option-checking '--prefix=/home/ts2/m_local/bin_p/Sage/paigaldatult/boehm_demers_weiser_garbage_collector'  '--with-gnu-ld' '--enable-cplusplus' '--enable-large-config' '--enable-handle-fork' 'CC=gcc' 'CFLAGS= -mtune=native -ftree-vectorize ' 'CXX=g++' 'CXXFLAGS= -mtune=native -ftree-vectorize ' --cache-file=/dev/null --srcdir=.
configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for ranlib... ranlib
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/param.h... yes
checking for getpagesize... yes
checking for working mmap... yes
checking for ANSI C header files... (cached) yes
checking for PIC compiler flag... -fPIC
checking whether gcc -fPIC causes __PIC__ definition... yes
checking for pthread_self in -lpthread... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating pkgconfig/atomic_ops.pc
config.status: creating pkgconfig/atomic_ops-uninstalled.pc
config.status: creating doc/Makefile
config.status: creating src/Makefile
config.status: creating src/atomic_ops/Makefile
config.status: creating src/atomic_ops/sysdeps/Makefile
config.status: creating tests/Makefile
config.status: creating src/config.h
config.status: executing depfiles commands
config.status: executing default commands
ts2@linux-0fiz:~/m_local/bin_p/Sage/kompileerimine/gc-7.2$ nice -n20 make
make[1]: Entering directory '/opt/2dot7TiB_k8vaketas/ts2/mittevarundatav/_home/m_local/bin_p/Sage/kompileerimine/gc-7.2'
depbase=`echo allchblk.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H   -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src  -fexceptions -mtune=native -ftree-vectorize  -fno-strict-aliasing -MT allchblk.lo -MD -MP -MF $depbase.Tpo -c -o allchblk.lo allchblk.c &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: Version mismatch error.  This is libtool 2.4.2, but the
libtool: definition of this LT_INIT comes from libtool 2.4.2.418.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2
libtool: and run autoconf again.
Makefile:1377: recipe for target 'allchblk.lo' failed
make[1]: *** [allchblk.lo] Error 63
make[1]: Leaving directory '/opt/2dot7TiB_k8vaketas/ts2/mittevarundatav/_home/m_local/bin_p/Sage/kompileerimine/gc-7.2'
Makefile:1517: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
ts2@linux-0fiz:~/m_local/bin_p/Sage/kompileerimine/gc-7.2$ uname -a
Linux linux-0fiz 3.16.7-29-desktop #1 SMP PREEMPT Fri Oct 23 00:46:04 UTC 2015 (6be6a97) x86_64 x86_64 x86_64 GNU/Linux
ts2@linux-0fiz:~/m_local/bin_p/Sage/kompileerimine/gc-7.2$ gcc --version
gcc (SUSE Linux) 4.8.3 20140627 [gcc-4_8-branch revision 212064]
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ts2@linux-0fiz:~/m_local/bin_p/Sage/kompileerimine/gc-7.2$ date
Sat Feb  6 03:00:15 EET 2016
ts2@linux-0fiz:~/m_local/bin_p/Sage/kompileerimine/gc-7.2$ echo $CFLAGS
-mtune=native -ftree-vectorize
ts2@linux-0fiz:~/m_local/bin_p/Sage/kompileerimine/gc-7.2$ echo $CXXFLAGS
-mtune=native -ftree-vectorize
ts2@linux-0fiz:~/m_local/bin_p/Sage/kompileerimine/gc-7.2$ echo $CC
gcc
ts2@linux-0fiz:~/m_local/bin_p/Sage/kompileerimine/gc-7.2$ echo $CXX
g++
ts2@linux-0fiz:~/m_local/bin_p/Sage/kompileerimine/gc-7.2$ 

AARCH64 support on FreeBSD

We need to add support for AArch64 to Boehm GC on FreeBSD.

Can someone take a look to this PR?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201183

Regards.

Assertion failure in reclaim.c: (hhdr)->hb_descr == 0

Current git master HEAD and also tag gc7_4_2 fail with error Assertion failure: reclaim.c:314 almost immediately, on a certain complex app, when I build bdwgc with

./configure --enable-cplusplus --enable-gc-assertions --enable-large-config

The failure goes away when built without the --enable-gc-assertions flag (and things seem to work fine). I don't have any simple way of reproducing this; its a large complex app using guile, and guile is the only component that calls bdwgc directly. (Note to self: its the AnaphoraUTest that fails)

Side remark: without --enable-large-config I was hitting Too many root sets. Now it works fine(barring above). Given today's large machines, perhaps its time for a --enable-super-large-config?

memory fault with incremental collection

I'm trying to use the GC in the memcached code base and running into the following issue. Note, this is a modified memcached setup so that the connection objects and various buffers per-connection for reading and writing to the network are managed by the GC. The storage engine for the key-value store is left alone, still uses malloc and reference counting.

1. Enable incremental collection
2. Connect to memcached server with one client and start generating load -- works fine.
3. Connect as above with a second client -- first client will have its connection shutdown as during a read system call an EFAULT will occur, so the memcached code kills that client.

I'm not sure why an EFAULT is occurring for the first client. The buffer that it is trying to read into is one allocated by GC_malloc and so I assume something is going wrong with the page protection for incremental collection. I'm not able to figure out more than that. Also worth noting that memcached is event based and uses libevent.

This is with 7.3alpha2 or with the release-7_2 github tag.

Completion of error handling

I have looked at a few source files for your current software. I have noticed that some checks for return codes are missing.

Would you like to add more error handling for return values from functions like the following?

• pthread_mutex_init ⇒ GC_init
• pthread_cond_wait ⇒ sem_wait

autoconf failures on mingw

I am trying to compile bdwgc 7.2 release on mysys/mingw, while libatomic_ops compile without any problems, it seems that there is some problems on bdwgc autoconf script (configure.ac), it throws this error while issuing autoconf command from the autogen.sh

configure.ac:70: error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:358: error: possibly undefined macro: AS_IF

if i added this exception lines into configure.ac
m4_pattern_allow([^dnl])
m4_pattern_allow([^AC_])
m4_pattern_allow([^AS_])
m4_pattern_allow([^m4])

it will succeed to generate the configure scripts but failed when configure process.

aclocal v 1.10
autoconf v 2.68

7.2alpha6 fails to compile with clang

Users of Homebrew have noticed the following problems when compiling with the default clang: 1 and 2.

The issue seems to be around the following macro:

libtool: compile:  /usr/bin/clang -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -Os -w -pipe -march=native -Qunused-arguments -c os_dep.c  -fno-common -DPIC -o .libs/os_dep.o
misc.c:943:7: error: array size is negative
      GC_STATIC_ASSERT((ptr_t)(word)(-1) > (ptr_t)0);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/private/gc_priv.h:2143:51: note: expanded from macro 'GC_STATIC_ASSERT'
# define GC_STATIC_ASSERT(expr) (void)sizeof(char[(expr)? 1 : -1])
                                                  ^~~~~~~~~~~~~~
1 error generated.

Nobody is quite sure what that macro is intended to be doing (whether it is a bug in clang or a bug in the macro which clang exposes), but in either case it seems like something we should report upstream.

It compiles cleanly with LLVM.

[patch] FreeBSD/arm32/mips support

Hi Ivan,

This patch updates the arm32 and mips code to match arm64, powerpc and x86.

--- include/private/gc_priv.h.orig  2015-07-19 06:04:50.556246052 +0200
+++ include/private/gc_priv.h   2015-07-19 06:08:05.602872722 +0200
@@ -2484,7 +2484,8 @@
 #endif

 #if defined(FREEBSD) && (defined(I386) || defined(X86_64) \
-                        || defined(AARCH64) || defined(POWERPC))
+                        || defined(AARCH64) || defined(POWERPC) \
+                        || defined(ARM32) || defined(MIPS))
 # include <machine/trap.h>
 # if !defined(PCR)
 #   define NEED_FIND_LIMIT
--- include/private/gcconfig.h.orig 2015-07-19 06:08:15.489919841 +0200
+++ include/private/gcconfig.h  2015-07-19 06:32:17.201553218 +0200
@@ -417,6 +417,10 @@
 #   define IA64
 #   define mach_type_known
 # endif
+# if defined(FREEBSD) && (defined(mips) || defined(__mips) || defined(_mips))
+#   define MIPS
+#   define mach_type_known
+# endif
 # if defined(FREEBSD) && defined(__sparc__)
 #   define SPARC
 #   define mach_type_known
@@ -1797,8 +1801,12 @@
 #       define DYNAMIC_LOADING
 #   endif
 #   ifdef FREEBSD
+#       define ALIGNMENT 4
 #       define OS_TYPE "FREEBSD"
-/* MPROTECT_VDB is not yet supported at all on FreeBSD/alpha. */
+#       ifndef GC_FREEBSD_THREADS
+#         define MPROTECT_VDB
+#       endif
+#       define FREEBSD_STACKBOTTOM
 #       define SIG_SUSPEND SIGUSR1
 #       define SIG_THR_RESTART SIGUSR2
                 /* SIGTSTP and SIGCONT could be used alternatively.     */
@@ -1806,17 +1814,9 @@
 #       ifdef __ELF__
 #           define DYNAMIC_LOADING
 #       endif
-/* Handle unmapped hole alpha*-*-freebsd[45]* puts between etext and edata. */
         extern char etext[];
-        extern char edata[];
-        extern char end[];
-#       define NEED_FIND_LIMIT
-#       define DATASTART ((ptr_t)(&etext))
-        ptr_t GC_find_limit(ptr_t, GC_bool);
-#       define DATAEND (GC_find_limit (DATASTART, TRUE))
-#       define DATAEND_IS_FUNC
-#       define DATASTART2 ((ptr_t)(&edata))
-#       define DATAEND2 ((ptr_t)(&end))
+#       define DATASTART GC_FreeBSDGetDataStart(0x1000, (ptr_t)etext)
+#       define DATASTART_USES_BSDGETDATASTART
 #   endif
 #   ifdef OSF1
 #       define OS_TYPE "OSF1"
@@ -2140,14 +2140,19 @@
 #   endif
 #   ifdef FREEBSD
       /* FreeBSD/arm */
-#     define ALIGNMENT 4
 #     define OS_TYPE "FREEBSD"
+#     ifndef GC_FREEBSD_THREADS
+#       define MPROTECT_VDB
+#     endif
+#     define SIG_SUSPEND SIGUSR1
+#     define SIG_THR_RESTART SIGUSR2
+#     define FREEBSD_STACKBOTTOM
 #     ifdef __ELF__
 #       define DYNAMIC_LOADING
 #     endif
-#     define HEURISTIC2
       extern char etext[];
-#     define SEARCH_FOR_DATA_START
+#     define DATASTART GC_FreeBSDGetDataStart(0x1000, (ptr_t)etext)
+#     define DATASTART_USES_BSDGETDATASTART
 #   endif
 #   ifdef DARWIN
       /* iOS */
--- os_dep.c.orig   2015-07-19 06:32:31.752699426 +0200
+++ os_dep.c    2015-07-19 06:38:30.764294718 +0200
@@ -3060,7 +3060,7 @@
 #     ifndef SEGV_ACCERR
 #       define SEGV_ACCERR 2
 #     endif
-#     if defined(AARCH64)
+#     if defined(AARCH64) || defined(ARM32) || defined(MIPS)
 #       define CODE_OK (si -> si_code == SEGV_ACCERR)
 #     elif defined(POWERPC)
 #       define AIM  /* Pretend that we're AIM. */

It was tested and worked as expected.

Please add support for OpenRISC/or1k architecture

Hi,

Please review and if OK accept this patch to add support for OpenRISC/or1k architecture. I am participating in a port for this architecture in Debian.

This was created against the version in Debian 7.2d, but can probably be applied fuzzily, or I can submit a patch against the latest code, or a pull request (files cannot be attached, but I pasted it below). Still, I think that it is better to review and discuss it first.

--- a/include/private/gcconfig.h
+++ b/include/private/gcconfig.h
@@ -148,6 +148,10 @@
 #    endif
 #    define mach_type_known
 # endif
+# if defined(__or1k__)
+#    define OR1K
+#    define mach_type_known
+# endif
 # if defined(DGUX) && (defined(i386) || defined(__i386__))
 #    define I386
 #    ifndef _USING_DGUX
@@ -1584,6 +1588,24 @@
 #   endif
 # endif

+# ifdef OR1K
+#   define CPP_WORDSZ 32
+#   define MACH_TYPE "OR1K"
+#   ifdef LINUX
+#     define OS_TYPE "LINUX"
+#     define DYNAMIC_LOADING
+      extern int _end[];
+#     define DATAEND (ptr_t)(_end)
+      extern int __data_start[];
+#     define DATASTART ((ptr_t)(__data_start))
+#     define ALIGNMENT 4
+#     ifndef HBLKSIZE
+#       define HBLKSIZE 4096
+#     endif
+#     define LINUX_STACKBOTTOM
+#   endif /* Linux */
+# endif
+
 # ifdef HP_PA
 #   define MACH_TYPE "HP_PA"
 #   ifdef __LP64__

Tests fail on Mac OS X Lion

Hi,

I'm currently trying to install bdw-gc as a dependency for TeXmacs under OS X Lion, using XCode-provided tools, resulting in a failure to run make check.

The MacPorts version (using standard GCC built from source) works, but I would really love to use only tools provided by XCode since it really is a pain to have to install/compile/update other GCCs...

You can check this thread on the Homebrew repo for more reports from other users (afaik, most of them are trying to install w3m, but the issue is the same) : Homebrew/legacy-homebrew#8609

Versions :

• BDW-GC 7.1 and 7.2alpha6
• Compilers: LLVM-GCC 4.2 and Clang-GCC 3.0 from XCode 4.2
• OS: OS X Lion 10.7.2

My make check output is below, although I don't know whether it'll be useful or not...

make  check-TESTS
Switched to incremental mode
Emulating dirty bits with mprotect/signals
typed alloc failed at 289
Test failed
/bin/sh: line 1: 90371 Abort trap: 6           ${dir}$tst
FAIL: gctest
Leaked composite object at 0x105621ee0 (tests/leak_test.c:12, sz=13, NORMAL)

Leaked composite object at 0x105621f20 (tests/leak_test.c:12, sz=12, NORMAL)

Leaked composite object at 0x105621f60 (tests/leak_test.c:12, sz=11, NORMAL)

Leaked composite object at 0x105621fa0 (tests/leak_test.c:12, sz=10, NORMAL)

Leaked composite object at 0x105621fe0 (tests/leak_test.c:12, sz=9, NORMAL)

Leaked composite object at 0x105620f20 (tests/leak_test.c:12, sz=8, NORMAL)

Leaked composite object at 0x105620f50 (tests/leak_test.c:12, sz=7, NORMAL)

Leaked composite object at 0x105620f80 (tests/leak_test.c:12, sz=6, NORMAL)

Leaked composite object at 0x105620fb0 (tests/leak_test.c:12, sz=5, NORMAL)

Leaked composite object at 0x105620fe0 (tests/leak_test.c:12, sz=4, NORMAL)

GC_debug_free: found smashed location at 0x105620fa8 in or near object at 0x105620fb0 (0b:0, sz=0)
GC_debug_free: found smashed location at 0x105620f78 in or near object at 0x105620f80 (EMPTY(smashed?):0, sz=0)
GC_debug_free: found smashed location at 0x105620f48 in or near object at 0x105620f50 (EMPTY(smashed?):0, sz=0)
GC_debug_free: found smashed location at 0x105620f18 in or near object at 0x105620f20(<smashed>, appr. sz = 9)
GC_debug_free: found smashed location at 0x105621fd8 in or near object at 0x105621fe0 (@b:0, sz=0)
GC_debug_free: found smashed location at 0x105621f98 in or near object at 0x105621fa0 (EMPTY(smashed?):0, sz=0)
GC_debug_free: found smashed location at 0x105621f58 in or near object at 0x105621f60 (?b:0, sz=0)
GC_debug_free: found smashed location at 0x105621f18 in or near object at 0x105621f20 (EMPTY(smashed?):0, sz=0)
GC_debug_free: found smashed location at 0x105621ed8 in or near object at 0x105621ee0(<smashed>, appr. sz = 25)
/bin/sh: line 1: 90390 Segmentation fault: 11  ${dir}$tst
FAIL: leaktest
Final heap size is 253943808
PASS: middletest
GC_check_heap_block: found smashed heap objects:
 0x108e5ffe8 in or near object at 0x108e5ffc0 (tests/smash_test.c:22, sz=40)

GC_check_heap_block: found smashed heap objects:
 0x108ed2f98 in or near object at 0x108ed2f70 (tests/smash_test.c:22, sz=40)
 0x108e5ffe8 in or near object at 0x108e5ffc0 (tests/smash_test.c:22, sz=40)

PASS: smashtest
PASS: hugetest
FAIL: staticrootstest
Leaked composite object at 0x10e0f1fe0 (tests/thread_leak_test.c:12, sz=4, NORMAL)

Leaked composite object at 0x10e0f1fb0 (tests/thread_leak_test.c:12, sz=4, NORMAL)

Leaked composite object at 0x10e0f1d40 (tests/thread_leak_test.c:12, sz=4, NORMAL)

Leaked composite object at 0x10e0f1e30 (tests/thread_leak_test.c:12, sz=4, NORMAL)

Leaked composite object at 0x10e0f1f80 (tests/thread_leak_test.c:12, sz=4, NORMAL)

PASS: threadleaktest
PASS: threadkey_test
PASS: initsecondarythread
usage: test_cpp number-of-iterations
Assuming 10 iters
Starting iteration 1
Assertion failure in tests/test_cpp.cc, line 116: nFreed <= nAllocated && nFreed >= .8 * nAllocated
FAIL: test_cpp
==================================
4 of 10 tests failed
Please report to [email protected]
==================================

Deadlock with winpthreads and parallel marking

A problem occurs with MinGW-w64, winpthreads and parallel marking.

I can reproduce it like this (on a 4-core machine running Windows 7):

1. install MSYS2 and mingw-w64-i686-gcc
2. ./configure --enable-threads=posix --enable-parallel-mark
3. make check

Or, because, gctest pops up an error dialogue with "write to stdout failed":

1. GC_LOG_FILE=log ./gctest.exe

gctest hangs in most runs. Setting GC_MARKERS=1 lets it complete.

I can also reproduce the problem with a simpler program that just calls GC_malloc many times.

The problem does not occur with --enable-threads=win32 --enable-parallel-mark
nor with --enable-threads=posix --disable-parallel-mark.

Build / install procedures need to be updated in README.md?

Per README.md, I tried building / installing bdwgc from git source:

[[email protected] bdwgc]$ make -f Makefile.direct 
cp Makefile.direct Makefile
CC=cc  MAKE=make ./build_atomic_ops.sh
./build_atomic_ops.sh: line 3: cd: libatomic_ops: No such file or directory
./build_atomic_ops.sh: line 4: ./configure: No such file or directory
make[1]: Entering directory `/home/jric/dev/bdwgc'
make[1]: *** No rule to make target `install'.  Stop.
make[1]: Leaving directory `/home/jric/dev/bdwgc'
make: *** [libatomic_ops-install] Error 2

The other option suggested in the README.md didn't work either, because there is no "configure" script, so I tried automake, which kept failing, and then I figured out I probably need to use cmake?

After running cmake, I was able to successfully "make" (if I didn't use -f Makefile.direct), but I still couldn't "make install" as mentioned in README.md:

[[email protected] bdwgc]$ sudo make install
[sudo] password for jric:
make: *** No rule to make target `install'. Stop.

I need the bdw-gc.pc file and the package installed into /usr/local/lib on the system. Can someone point me in the right direction for how to do this? I really need this package to build latest version of fontforge.

I am happy to contribute changes back to the README.md file.

OpenBSD 5.2 rthreads pthread_suspend_np

Since version 5.2, OpenBSD switched to their in-kernel pthread implementation called rthreads. These don't implement pthread_suspend_np and pthread_resume_np (yet?). pthread_stop_world.c uses those two functions in GC_OPENBSD_THREADS ifdefs, so gc can't be compiled on OpenBSD 5.2 and up so far.

GC_mark_stack_bottom interpreted as heap pointer?

While investigating a bug report in CACAO, I translated the relevant bits of the test program to C, and now I can reproducibly make the GC run out of memory. The orphaned entries form a chain of entries, so holding on to just one of them ensures that nothing is ever reclaimed. Using GC_TRACE and GC_generate_random_backtrace, I can at least make a guess at what happens here. GC_mark_stack_bottom () is in the root set -- what for? -- and points to the lower heap bound (). Following it, ..0x30 gets marked for some reason, and it's game over from there. This happens with 7.2d (and with every 7+ release). Release 6.8 is the most recent one I could find which does not behave that way.

I'm aware that the test is probably the worst possible scenario for a conservative garbage collector, but I still wonder why the GC_mark_stack_bottom variable is treated as a heap pointer. It's also possible that my interpretation of the trace output is off. It's not easy for an outsider to find out what's really going on.

EDIT: Hmm, it doesn't seem to be possible to add an attachment here… – https://github.com/Ringdingcoder/dumpingground/blob/master/gc-chain.c

Assertion failure in GC_free -- C++ std::vector

Where to begin?

I have a C++ library making very heavy use of const std::vector to store pointers. Until a few days ago, these vectors of pointers were always arranged in trees (no cycles). A few days ago, I added std:set (that also stores pointers) in such a way that cycles may form. I immediately got crashes (but only when gc is compiled in, else not), suggesting a premature collection, presumably because some pointers were invisible; but that's not what I seem to be finding.

So:
on generic ubuntu 12.04 but with gcc-4.7.3
git pull of bdwgc & atomic_ops
./configure --enable-cplusplus --enable-gc-assertions
make; make install

The crash is almost immediate:
Assertion failure: malloc.c:506

The relevant part of the stack trace:
#1 0x00007ffff6dc5b8b in __GI_abort () at abort.c:91
#2 0x00007ffff7b7bb70 in GC_free (p=) at malloc.c:534
#3 0x0000000000414c11 in deallocate (__p=, this=,

GC_n=<optimized out>) at /usr/local/include/gc/gc_allocator.h:137

#4 _M_deallocate (__p=, this=, __n=)

at /usr/include/c++/4.7/bits/stl_vector.h:175

#5 ~_Vector_base (this=0x7fffffffdf70, __in_chrg=)

at /usr/include/c++/4.7/bits/stl_vector.h:161

#6 ~vector (this=0x7fffffffdf70, __in_chrg=)

at /usr/include/c++/4.7/bits/stl_vector.h:404

#7 Uniq (sset=0x68a500, this=0x682880)

Some notes about my code:
compiled with -std=c++0x link with libgc and libgccpp
My code base is fairly small, about 6KLOC total.
My vectors are:
std::vector<Atom*, gc_allocator<Atom*> >
with class Atom : public gc {...};

The failing function Uniq is getting a vector that was constructed on-stack, specifically, by a function that returned a copy of the vector that had been constructed on stack.

I'm stumped as to how to proceed. I've already put in 10+ hours of debugging to get to here. Based on past experience, it will take at least another 30+ hours to make forward progress, maybe more.

Again: my code base is small, its been working great for months, it compiles w/o warnings, its not doing anything strange or funky with pointers (other than storing them in std::vector, std::map and std::set) After a long, hard day, I might be able to create a small test program showing the failure ... maybe.

BTW: Before I turned on --enable-gc-assertions, I was seeing other crashes, much much later in my code, with gc-7.2d and also the default gc-7.1 that comes with ubuntu 12.04 These were preceded by reports of a smashed heap. Since the code runs fine w/o gc, this suggests that somehow, something is getting released early, presumably because some pointer is not visible to bdwgc. So I double-checked: all of my pointers are either on-stack, or in std::vector, everything inherits from gc, or uses gc_allocator, etc. Thus, I was very surprised by the assert failure very early in my code; its a radically different failure than the previous smashed heaps.

I'm somewhat concerned that its a gcc-4.7 bug. Or more likely some new stl c++0x bug ...

I dread the thought of trying to debug the innards of std:vector and trying to figure out how the compiler laid it out on stack, and how it all interacted with gc_allocator... is there anything easy/stupid/obvious I can try?

In the future, I was planning on mixing this stuff together with the multi-threading openmp built into the compiler, but am now getting cold feet. I'm wondering whether reference-counting with some boost shared pointer lib might be safer, given all the other STL tech, and my small code base. Maybe. Or maybe not. Advice?

build fails

The build process fails due to an error during autoreconf.

Trace:

$ autoreconf -i
C:\MinGW\bin\libtoolize: putting auxiliary files in `.'.
C:\MinGW\bin\libtoolize: copying file `./ltmain.sh'
C:\MinGW\bin\libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
C:\MinGW\bin\libtoolize: copying file `m4/libtool.m4'
C:\MinGW\bin\libtoolize: copying file `m4/ltoptions.m4'
C:\MinGW\bin\libtoolize: copying file `m4/ltsugar.m4'
C:\MinGW\bin\libtoolize: copying file `m4/ltversion.m4'
C:\MinGW\bin\libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:117: error: possibly undefined macro: AC_MSG_ERROR
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:401: error: possibly undefined macro: AS_IF
autoreconf-2.67: /mingw/bin/autoconf-2.67 failed with exit status: 1

Specs:

• git bdwgc
• gcc.exe (GCC) 4.5.2
• MinGW version 0.1-alpha-5.1
• MSYS 1.0
• Windows 7 Professional x64
• MacBook Pro

libc5 support code in os_dep.c breaks compilation with musl libc

Trying to compile boehm-gc on a linux system with musl libc (http://musl-libc.org) fails:

In file included from os_dep.c:47:0:
/usr/include/asm/sigcontext.h:134:8: error: redefinition of 'struct _fpstate'
 struct _fpstate {
        ^
In file included from /usr/include/signal.h:243:0,
                 from ./include/private/../gc_pthread_redirects.h:50,
                 from ./include/private/../gc.h:923,
                 from ./include/private/gc_priv.h:40,
                 from os_dep.c:17:
/usr/include/bits/signal.h:37:16: note: originally defined here
 typedef struct _fpstate {
                ^
In file included from os_dep.c:47:0:
/usr/include/asm/sigcontext.h:157:8: error: redefinition of 'struct sigcontext'
 struct sigcontext {
        ^
In file included from /usr/include/signal.h:243:0,
                 from ./include/private/../gc_pthread_redirects.h:50,
                 from ./include/private/../gc.h:923,
                 from ./include/private/gc_priv.h:40,
                 from os_dep.c:17:
/usr/include/bits/signal.h:49:8: note: originally defined here
 struct sigcontext {
        ^
make[1]: *** [os_dep.lo] Error 1
make: *** [all-recursive] Error 1

Because __GLIBC__ is not declared the file assumes that musl is libc5 (!) and includes

bdwgc/os_dep.c

Line 44 in 0d147af

# include <asm/sigcontext.h>

a conflicting kernel header. Everything compiles fine after removing this line.

Is libc5 still relevant? If not, could this code be removed (and maybe the stuff around it cleaned up)? If it is still supported, I'll try to come up with an autoconf test. (However I have no idea how to get a libc5 system to test it.)

Support for Haiku Platform

Support for the operating system Haiku, the open source successor to beos.

Main Homepage:
https://www.haiku-os.org

Development Websites:
https://dev.haiku-os.org/
https://www.haiku-os.org/development

boehm-gc incompatible with aslr on darwin11

GC_mark_from crashes on executable built on MacOSX Lion, which has ASLR option on
Please see detailed description at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179

7.5.0: include <gc.h> doesn't work, first two tests fail

On OS X 10.10, Yosemite

When building with the given instructions, the first two tests fail the "make check" command, gctests and something else. In addition, using "include <gc.h>" with -lgc on clang ang gcc compilers does not work. Please help out fast? Need this garbage collector soon for AST construction.

LIBTOOL undefined

On a current LinuxMint 64 with current git version of bdwgc & libatomic_ops:

...
$ autoreconf -vif
autoreconf: Entering directory .' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4 autoreconf: configure.ac: tracing autoreconf: configure.ac: adding subdirectory libatomic_ops to autoreconf autoreconf: Entering directorylibatomic_ops'
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:14: installing './compile'
configure.ac:5: installing './config.guess'
configure.ac:5: installing './config.sub'
configure.ac:8: installing './install-sh'
configure.ac:8: installing './missing'
src/Makefile.am:5: error: Libtool library used but 'LIBTOOL' is undefined
src/Makefile.am:5: The usual way to define 'LIBTOOL' is to add 'LT_INIT'
src/Makefile.am:5: to 'configure.ac' and run 'aclocal' and 'autoconf' again.
src/Makefile.am:5: If 'LT_INIT' is in 'configure.ac', make sure
src/Makefile.am:5: its definition is in aclocal's search path.
src/Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
autoreconf: automake failed with exit status: 1
$ libtool --version
libtool (GNU libtool) 2.4.2
Written by Gordon Matzigkeit [email protected], 1996

Deadlock due to race when using thread discovery and parallel GC on Darwin

We ran into a deadlock when we enabled thread discovery in RoboVM. See robovm/bdwgc@0458ff8 and robovm/robovm#1113. Feel free to cherry-pick this or let me know if you want me to submit this as a PR. It compiles and runs fine for OSX/iOS x86/ARM 32/64-bit and Linux x86 32/64-bit. Reproducing is easy on OSX. Just compile a simple C program which calls GC_INIT() linked with a libgc compiled with --enable-parallel-mark=yes and -DGC_DISCOVER_TASK_THREADS. Run that program many times (I had to run it > 100 times) and it will eventually deadlock with call stacks similar to the one in robovm/robovm#1113.

Remove windows-untested folder

If CMake can generate MS Visual Studio 6.0, 7.0, 8.0 project files then no need to keep these IDE-specific files in the repository.

7.4.0: include/gc_cpp.h: Declaring and assigning breaks non gcc compiles

The immediate setting of a variable when declaring it in include/gc_cpp.h breaks the Sun Studio compiler as invalid syntax. On Solaris at least all values are already zero'd at declaration anyway so it's not required.

host:/var/tmp/bdw-gc-7.4.0/include root# grep ' = 0' gc_cpp.h
                          GC_NS_QUALIFY(GCCleanUpFunc) cleanup = 0,
                          void* clientData = 0 );
                              GC_NS_QUALIFY(GCCleanUpFunc) cleanup = 0,
                              void* clientData = 0 );

I use this to fix for compiling, note the space before the equals, so the normal assigns still work in the header file.

perl -pe 's# = 0##' -i include/gc_cpp.h

Packages for 7.4.0 on Solaris can be found at:
http://www.ibiblio.org/pub/packages/solaris/sparc/

misc.c/GC_log file descriptor is static

There's no way to programmatically change or set the file descriptor for logging.
In my own copy, I've made a function for setting it, but it might be simpler to just make it visible?

Compilation fails on Mac OS X

�See http://stackoverflow.com/questions/6929826/building-libgc-fails-on-mac-os-x-10-6-snow-leopard-and-require-xopen-source for details. Fails on OS X 10.7 as well.

GC_realloc should call GC_free if pointer is not NULL and size is 0

Most implementations of realloc calls free if pointer is not NULL and size is zero:

• http://linux.die.net/man/3/realloc

  if size is equal to zero, and ptr is not NULL, then the call is equivalent to free(ptr).

• https://msdn.microsoft.com/en-us/library/xbebcx7d.aspx

  If size is zero, then the block pointed to by memblock is freed; the return value is NULL, and memblock is left pointing at a freed block.

• http://www.cplusplus.com/reference/cstdlib/realloc/

  C90: Otherwise, if size is zero, the memory previously allocated at ptr is deallocated as if a call to free was made, and a null pointer is returned.
  C99/C11: If size is zero, the return value depends on the particular library implementation: it may either be a null pointer or some other location that shall not be dereferenced.

Notable exceptions are:

• https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/realloc.3.html

  If size is zero and ptr is not NULL, a new, minimum sized object is allocated and the original object is freed.

• https://www.freebsd.org/cgi/man.cgi?realloc(3) - no special comments at all

As an alternative, pointer to fixed position could be returned.

Race conditions between thread termination and garbage collection

This was discussed before, but I don't know if it was resolved: http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2010-March/003793.html

I use github master.

(gdb) info threads
  Id   Target Id         Frame 
  11   Thread 0x7f7dfd962700 (LWP 2022) 0x00007f7e04dcd482 in do_sigsuspend (set=0x7f7e059db240 <suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
  10   Thread 0x7f7dfe163700 (LWP 2021) 0x00007f7e04dcd482 in do_sigsuspend (set=0x7f7e059db240 <suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
  9    Thread 0x7f7dfe964700 (LWP 2020) 0x00007f7e04dcd482 in do_sigsuspend (set=0x7f7e059db240 <suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
  8    Thread 0x7f7dff165700 (LWP 2019) 0x00007f7e04dcd482 in do_sigsuspend (set=0x7f7e059db240 <suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
  7    Thread 0x7f7dff966700 (LWP 2018) 0x00007f7e04dcd482 in do_sigsuspend (set=0x7f7e059db240 <suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
  6    Thread 0x7f7e00167700 (LWP 2017) 0x00007f7e04dcd482 in do_sigsuspend (set=0x7f7e059db240 <suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
  5    Thread 0x7f7e00968700 (LWP 2016) 0x00007f7e04dcd482 in do_sigsuspend (set=0x7f7e059db240 <suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
  4    Thread 0x7f7e01169700 (LWP 2015) sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
  3    Thread 0x7f7e0216b700 (LWP 2013) __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
  2    Thread 0x7f7e04970700 (LWP 2008) pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
* 1    Thread 0x7f7e05c05b40 (LWP 2007) 0x00007f7e04dcd482 in do_sigsuspend (set=0x7f7e059db240 <suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31

It seems that threads 2, 3, 4 are dead locked.

(gdb) thread 4
[Switching to thread 4 (Thread 0x7f7e01169700 (LWP 2015))]
#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
85  ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S: No such file or directory.
(gdb) bt
#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
#1  0x00007f7e057bcf82 in GC_stop_world () at pthread_stop_world.c:662
#2  0x00007f7e057a913e in GC_stopped_mark (stop_func=stop_func@entry=0x7f7e057a8c40 <GC_never_stop_func>) at alloc.c:646
#3  0x00007f7e057a9c99 in GC_try_to_collect_inner (stop_func=0x7f7e057a8c40 <GC_never_stop_func>) at alloc.c:486
#4  0x00007f7e057a9f0a in GC_try_to_collect_general (stop_func=stop_func@entry=0x0, force_unmap=force_unmap@entry=0) at alloc.c:1065
#5  0x00007f7e057a9fdd in GC_gcollect () at alloc.c:1089

(gdb) thread 3
[Switching to thread 3 (Thread 0x7f7e0216b700 (LWP 2013))]
#0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
135 in ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S
(gdb) bt
#0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007f7e055864b9 in _L_lock_909 () from /lib/x86_64-linux-gnu/libpthread.so.0
#2  0x00007f7e055862e0 in __GI___pthread_mutex_lock (mutex=0x7f7e059daca0 <GC_allocate_ml>) at ../nptl/pthread_mutex_lock.c:79
#3  0x00007f7e057bbed5 in GC_thread_exit_proc (arg=arg@entry=0x2662c00) at pthread_support.c:1409
#4  0x00007f7e057bacad in GC_inner_start_routine (sb=<error reading variable: value has been optimized out>, arg=<error reading variable: value has been optimized out>) at pthread_start.c:63
#5  0x00007f7e057b5a42 in GC_call_with_stack_base (fn=<optimized out>, arg=<optimized out>) at misc.c:1925
#6  0x00007f7e055840a4 in start_thread (arg=0x7f7e0216b700) at pthread_create.c:309
#7  0x00007f7e04e7e04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

(gdb) thread 2
[Switching to thread 2 (Thread 0x7f7e04970700 (LWP 2008))]
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
185 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such file or directory.
(gdb) bt
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f7e057bc8f7 in GC_wait_marker () at pthread_support.c:2121
#2  0x00007f7e057b2cea in GC_help_marker (my_mark_no=my_mark_no@entry=30) at mark.c:1186
#3  0x00007f7e057bc8cc in GC_mark_thread (id=<optimized out>) at pthread_support.c:380
#4  0x00007f7e055840a4 in start_thread (arg=0x7f7e04970700) at pthread_create.c:309
#5  0x00007f7e04e7e04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

serious problem with bdw-gc.pc

Please have a look at this report: fontforge/fontforge#1274

The corollary of it is that future versions of bdw-gc.pc should use numerical versions only. For example, the first alpha release for version 7.3 should be identified in the 'Version:' field as e.g. '7.2.90' and not '7.3alpha1'.

Trouble with gc-7.2d compiling against musl libc

On behalf of John Spencer [email protected]:

Hi Ivan,

did the results of "make check" give you any clue ?

On 01/08/2013 11:31 AM, Ivan Maidanski wrote:

which algorithm is used for detection of main stack base in your case? which macro is defined - STACKBOTTOM, HEURISTIC1, LINUX_STACKBOTTOM?

out of these 3, only LINUX_STACKBOTTOM seems to be defined (i added

warnings into os_dep.c in order to find out)

Seems to be correct.
Does GC_get_main_stack_base return reasonable value?

how can i check ?
What is the difference between this value and address of any local var of main() function? (It should not be bigger than several K.) Is this value bigger than that local var address? (stack grows down on your target, right?)

~/GC/bdwgc # cat test.c

include "include/private/gc_priv.h"

include <stdio.h>

int main() {
int a;
dprintf(2, "a: %p, stack: %p\n", &a, GC_get_main_stack_base());
}

~/GC/bdwgc # gcc test.c -L".libs/" -lgc
~/GC/bdwgc # LD_LIBRARY_PATH=.libs ./a.out
a: 0x7fff6ff6728c, stack: 0x7fff6ff672e0
~/GC/bdwgc #

in any case, I'd welcome advice on how to workaround this issue, so that
i get a working libgc.so in order to use inkscape.
Thanks for reporting the problem, I'll definitely fix the gc source if we understand how to do it correctly. (Typically, first I apply the fixes to master branch and, then, cherry-pick to 7.2 release.)

thank you. is there anything else i can help with in order to get this
fixed ?
Also, static data roots should be checked (GC_static_roots[], all global/static variables should be within one of the regions).

how can i check ? List all root ranges.
Compile with linker map output, it will show addresses of global variables. These addresses (excluding read-only data) must be inside of a root range.

sorry, i don't know how to do that. please provide a test program and/or
required command line.

i tried:
~/GC/bdwgc # gcc -shared -fPIC -DPIC .libs/allchblk.o .libs/alloc.o
.libs/blacklst.o .libs/checksums.o .libs/db
g_mlc.o .libs/dyn_load.o .libs/finalize.o .libs/gc_dlopen.o
.libs/gcj_mlc.o .libs/headers.o .libs/mach_dep.o .lib
s/malloc.o .libs/mallocx.o .libs/mark.o .libs/mark_rts.o .libs/misc.o
.libs/new_hblk.o .libs/obj_map.o .libs/os_d
ep.o .libs/pcr_interface.o .libs/ptr_chck.o .libs/real_malloc.o
.libs/reclaim.o .libs/specific.o .libs/stubborn.o
.libs/thread_local_alloc.o .libs/typd_mlc.o .libs/fnlz_mlc.o -ldl
-Wl,-soname -Wl,libgc.so.1 -o .libs/libgc
.so.1.0.3 -Wl,--print-map > link.map
but the resulting file does not contain any reference to GC_static_roots

link.map: http://sprunge.us/gHCQ

maybe objdump or readelf can do what you want ?

i uploaded the entire ~/GC directory including all object files (and
.git dir) here for your convenience:
http://mirror.wzff.de/sabotage/GC.tar.gz (10 MB)

in case you want to try yourself (i suggest you do so, since i am not an
expert with BOEHM GC internals), here is an image file of sabotage linux
(150 MB only)

http://mirror.wzff.de/sabotage/sabotage-0.9.7-x86_64-898897d9.img.xz

extract using
xzcat sabotage-0.9.7-x86_64-898897d9.img.xz > sabotage.img

you can directly start it in qemu using

qemu-system-x86_64 sabotage.img

or convert to virtual box hdd format with
VBoxManage convertfromraw sabotage.img sabotage.vdi

root pass is "sabotage"

the only thing missing in the image is libtool, but this is not required
if you simply unpack the above GC tarball which has the configure script
already generated.
otherwise libtool compiles without any patches from source.
the other auto* utils, gcc, binutils, gdb, strace, etc are installed.

if you need network connectivity, try "dhclient eth0" or the usual ifconfig.

if you want to connect to the vm using SSH use :
source /src/config
butch install sshd-keys
/bin/sshd

latest musl precompiled is available here
http://mirror.wzff.de/sabotage/musl.tar.gz (700KB)
just unpack into /opt and everything will automatically be up-to-date.
(the musl installed in the image is one release behind, i am unsure if
it makes any difference though.)

thanks,
--JS

NO_GETCONTEXT except for glibc on linux

Had a problem building with musl-libc. I guess only glibc still supports getcontext so I recommend a patch like:

--- gc-7.4.2/./include/private/gcconfig.h
+++ ./include/private/gcconfig.h
@@ -2622,7 +2622,7 @@
 #if ((defined(UNIX_LIKE) && (defined(DARWIN) || defined(HURD) \
                              || defined(OPENBSD) || defined(ARM32) \
                              || defined(MIPS) || defined(AVR32))) \
-     || (defined(LINUX) && (defined(SPARC) || defined(M68K))) \
+     || (defined(LINUX) && (!defined(__gnu_linux__))) \
      || ((defined(RTEMS) || defined(PLATFORM_ANDROID)) && defined(I386))) \
     && !defined(NO_GETCONTEXT)
 # define NO_GETCONTEXT

Building with win32 threads on mingw / Windows 7 32-bit

Hi,

I'm having the problem exactly described here: http://www.mail-archive.com/[email protected]/msg00401.html

Although the thread is from 2010, the problem still seems to be present.

In summary:

• I'm building on MinGW, with GCC 4.8.1, 32-bit platform, win32 thread model
• I have bdwgc and libatomic_ops checked out from the latest version, and ran autoreconf -i on both of them with a recent autoconf (2.69) on another machine.
• When compiling after a ./configure --enable-threads=win32, none of the object files have any threading symbol in there (one would expect GC_CreateThread@24 for example).
• Trying to bypass that, ie. doing CPPFLAGS=-DWIN32_THREADS ./configure --enable-threads=win32 gives the appropriate symbols in win32_threads.o, as seen in this gist but then yields link errors, as seen in that gist.

The linker errors seem to be for those symbols in particular:

• GC_check_finalizer_nested: defined in both finalizer.c and win32_threads.c
• GC_do_blocking_inner: defined in both misc.c and win32_threads.c
• GC_is_static_root: undefined reference in ptr_chck.c
• GC_write_cs: undefined reference in win32_threads.c

As for the first two, this happens because in those parts of misc.c and finalizer.c, the THREADS symbol doesn't seem to be defined, although it should be. Manually defining THREADS (e.g. adding -DTHREADS to CPPFLAGS) only brings more problems.

Hence my questions:

1. Isn't --enable-threads=win32 supposed to produce a GC build with Win32 threads support?
2. Why isn't THREADS defined for misc.c and finalizer.c?
3. How do I get a Win32-threads-enabled build working at all?

Bonus question:

1. Is the DllMain approach to watching new threads on Windows deprecated or can it still be used? It seems to be the easiest (although it requires distributing libgc-1.dll)

Here are the config.log for bdwgc and my GCC version information: https://gist.github.com/nddrylliog/97a67bc609215a363aff

Thanks in advance for your time!

Bug: the last allocated object can not be finalized? Shall we clear the stack after we construct the gc_cleanup object?

Here is my test source:

#include <vector>

#include "gc_cpp.h"

std::vector<int> calc;
class AA : virtual public GC_NS_QUALIFY(gc_cleanup)
{
public:
    int c;
    static int idx;
    AA()
    {
        c = idx++;
        calc.push_back(c);
    }
    virtual ~AA()
    {
        calc.erase(std::find(calc.begin(), calc.end(), c));
        idx--;
        return;
    }
};
int AA::idx = 0;

int main()
{
    GC_INIT();
    for (int i = 0; i < 256; i++)
    {
        AA* aaa = new AA();
    }

    GC_gcollect();
    GC_invoke_finalizers();
    int c = AA::idx;
    int d = calc.size();
    int id = calc[0];
    return(0); //break point
}

When breaked on return, I saw the value of c is 1, not 0 as expected. d is 1 as well. The ID of the left object is 255 which means the latest allocated object.
My host infomation is AMD64-windows 6.2, and the program is in X86 mode.
I use CMake 3.2.1 to configure libgc of latest master branch, and only enabled 'enable_cplusplus' flag.

Problems building the testsuite using MinGW-w64

Hello. I'm building libgc 7.2e for Windows with POSIX thread support via w32-pthreads. It is for GNU guile and guile locks up inside RtlExitUserThread for some reason. That's why I want to run the testsuite inside gc-7.2/tests to figure out the problem. But "make test" only makes a single exeutable in the root directory, it doesn't build the tests inside ./tests. ./tests only includes an unfinished CMakeLists.txt for Windows and a tests.am file. So how do I build the testsuite?

test_cpp.cc FAILs with GCC and -std=gnu++14

GCC 6 defaults to -std=gnu++14 which makes test_cpp.cc FAIL with

Assuming 10 iters
Starting iteration 1
*** Error in `/home/abuild/osc-build-root/home/abuild/rpmbuild/BUILD/gc-7.4.2/.libs/test_cpp': free(): invalid pointer: 0x00000000006f8fe0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7364f)[0x7ffff71ac64f]
/lib64/libc.so.6(+0x78eae)[0x7ffff71b1eae]
/lib64/libc.so.6(+0x79b87)[0x7ffff71b2b87]
/home/abuild/osc-build-root/home/abuild/rpmbuild/BUILD/gc-7.4.2/.libs/tes

at

    for (i = 0; i < 1000; i++) {
        A* a = (A*) Undisguise( as[ i ] );
        B* b = (B*) Undisguise( bs[ i ] );
        a->Test( i );
        delete a;

^^^^

I suspect this has sth to do with the more recent standards allocator changes and the wrapping
no longer working properly. It works when specifying -std=gnu++98 manually (with GCC 6).

I have tested gc 7.4.2 sofar.

GC_collect_a_little always triggers full collection

Hello! I have a program that basically looks like this:

int main(int argc, char ** argv)
{
  int quit = 0;

  GC_INIT();
  GC_set_time_limit(10);
  GC_set_full_freq(100000);
  GC_set_free_space_divisor(1);
  GC_enable_incremental();

  GC_disable();

  while (!quit)
  {
       // * 
       // * Run some logic, allocate some temporary objects
       // *

      int n = 0;

      GC_enable();
      for(int i = 0; i < 100; ++i)
         n += GC_collect_a_little();
      GC_disable();


      printf("n=%d, bytes=%d", GC_get_bytes_since_gc(), n);
  }

  return 0;
}

It seems like no matter how I configure the GC or how many objects I allocate, the output either looks like this:

n=0, bytes=0
n=0, bytes=0
n=0, bytes=0
...

Or this:

n=0, bytes=1124...
n=0, bytes=2342...
n=0, bytes=4423...
n=0, bytes=0
...

Given the output, and the fact that GC_collect_a_little is supposed to return a nonzero value when there's more work to be done, I can only conclude that it triggers a full collection, either on each iteration or every other iteration, depending on the amount of garbage. The GC library has been compiled on OSX, with --disable-threads, without MUNMAP. Is there some fault with my code/configuration preventing incremental collection, or is this a bug?

7.4.0: disclaim_test always fails

(I commented out the test_cpp test to move forward, it's still broken)

host:/var/tmp/bdw-gc-7.4.0 root# gmake check
gmake[1]: Entering directory `/var/tmp/bdw-gc-7.4.0'
/usr/local/bin/gmake  libstaticrootslib_test.la libstaticrootslib2_test.la cordtest gctest leaktest middletest smashtest hugetest realloc_test staticrootstest  threadleaktest threadkey_test subthreadcreate_test initsecondarythread_test  disclaim_test disclaim_bench
gmake[2]: Entering directory `/var/tmp/bdw-gc-7.4.0'
gmake[2]: `libstaticrootslib_test.la' is up to date.
gmake[2]: `libstaticrootslib2_test.la' is up to date.
gmake[2]: `cordtest' is up to date.
gmake[2]: `gctest' is up to date.
gmake[2]: `leaktest' is up to date.
gmake[2]: `middletest' is up to date.
gmake[2]: `smashtest' is up to date.
gmake[2]: `hugetest' is up to date.
gmake[2]: `realloc_test' is up to date.
gmake[2]: `staticrootstest' is up to date.
gmake[2]: `threadleaktest' is up to date.
gmake[2]: `threadkey_test' is up to date.
gmake[2]: `subthreadcreate_test' is up to date.
gmake[2]: `initsecondarythread_test' is up to date.
gmake[2]: `disclaim_test' is up to date.
gmake[2]: `disclaim_bench' is up to date.
gmake[2]: Leaving directory `/var/tmp/bdw-gc-7.4.0'
/usr/local/bin/gmake  check-TESTS
gmake[2]: Entering directory `/var/tmp/bdw-gc-7.4.0'
gmake[3]: Entering directory `/var/tmp/bdw-gc-7.4.0'
PASS: cordtest
PASS: 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
FAIL: disclaim_test
PASS: disclaim_bench
gmake[4]: Entering directory `/var/tmp/bdw-gc-7.4.0'
gmake[5]: Entering directory `/var/tmp/bdw-gc-7.4.0'
gmake[5]: Nothing to be done for `all-am'.
gmake[5]: Leaving directory `/var/tmp/bdw-gc-7.4.0'
gmake[4]: Leaving directory `/var/tmp/bdw-gc-7.4.0'
============================================================================
Testsuite summary for gc 7.4.0
============================================================================
# TOTAL: 14
# PASS:  13
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See ./test-suite.log
Please report to [email protected]
============================================================================
gmake[3]: *** [test-suite.log] Error 1
gmake[3]: Leaving directory `/var/tmp/bdw-gc-7.4.0'
gmake[2]: *** [check-TESTS] Error 2

host:/var/tmp/bdw-gc-7.4.0 root# cat disclaim_test.log
Assertion failure, line 102: p->checksum == checksum
Threaded disclaim test.

DEBUG: Destruct 100401000 = (1003fa640, 0)
DEBUG: checksum 86802:
DEBUG: p->checksum 86802:

DEBUG: Destruct 100401020 = (0, 0)
DEBUG: checksum 782:
DEBUG: p->checksum 782:

DEBUG: Destruct 100401080 = (0, 0)
DEBUG: checksum 782:
DEBUG: p->checksum 782:

DEBUG: Destruct 1004010a0 = (100400f60, 1003f59a0)
DEBUG: checksum 4206810:
DEBUG: p->checksum 10948:

Problem section (and debugging mods)

host:/var/tmp/bdw-gc-7.4.0 root# vi  tests/disclaim_test.c
     82 void GC_CALLBACK pair_dct(void *obj, void *cd)
     83 {
     84     pair_t p = obj;
     85     int checksum;
     86 
     87     /* Check that obj and its car and cdr are not trashed. */
     88 /* #   ifdef DEBUG_DISCLAIM_DESTRUCT */
     89 /* #   endif */
     90     my_assert(GC_base(obj));
     91     my_assert(p->is_valid);
     92     my_assert(!p->car || p->car->is_valid);
     93     my_assert(!p->cdr || p->cdr->is_valid);
     94     checksum = 782;
     95     if (p->car) checksum += p->car->checksum;
     96     if (p->cdr) checksum += p->cdr->checksum;
     97     /* if (p->checksum != checksum) { */
     98         fprintf(stdout, "DEBUG: Destruct %p = (%p, %p)\n", (void *)p, (void *)p->car, (void *)p->cdr);
     99         fprintf(stdout, "DEBUG: checksum %d:\n", checksum);
    100         fprintf(stdout, "DEBUG: p->checksum %d:\n\n", p->checksum);
    101     /* } */
    102     my_assert(p->checksum == checksum);
    103 
    104     /* Invalidate it. */
    105     p->is_valid = 0;
    106     p->checksum = 0;
    107     p->car = cd;
    108     p->cdr = NULL;
    109 }

7.3alpha3 not finishing test on MingW with c++ options

on behalf of Joshua Scholar [email protected]:

I compiled 7.3alpha on MinGW. I used ivmai's advice and ran ./autogen.sh on
Linux and copied it back instead of running "autoreconf -vif" on windows.

A plain compile passed all tests.

But I just recompiled by doing
./configure --prefix=/MinGW --enable-cplusplus --enable-threads=win32
--enable-static --enable-shared
make clean
make
make check

But the check never finishes. After passing chordtest, gctest and leaktest
it hangs in middletest

I'm gonna post my email address for anyone to give me advice here...

JoshuaScholar (at) gmail etc.

Thanks

By the way the gmane post gave me an error of:
"You have lines longer than 80 characters. Fix that."
excuse me for the line breaks I'm gonna put in the middle of things.

7.4.0: make check fails to build on Solaris with Sun Studio

On many versions of Solaris with Sun Studio:

libtool: link: cc -xtarget=ultra -m64 -xcode=pic32 -O -I/usr/local/include -DGC_SOLARIS_THREADS -DGC_PTHREADS -o .libs/initsecondarythread_test initsecondarythread.o  -L/usr/local/lib ./.libs/libgc.so -L/usr/lib/lwp/ -lpthread -lrt -ldl -R/usr/local/lib -R/usr/lib/lwp/
cc: Warning: -xarch=native has been explicitly specified, or implicitly specified by a macro option, -xarch=native on this architecture implies -xarch=sparcvis which generates code that does not run on pre UltraSPARC processors
source='tests/test_cpp.cc' object='test_cpp.o' libtool=no \
DEPDIR=.deps depmode=none /bin/bash ./depcomp \
CC -xtarget=ultra -m64 -xcode=pic32 -DHAVE_CONFIG_H   -I./include -I./include -I/usr/local/include   -I/usr/local/include  -I/usr/local/include -c -o test_cpp.o `test -f 'tests/test_cpp.cc' || echo './'`tests/test_cpp.cc
"./include/gc_allocator.h", line 132: Warning: The variable traits has not yet been assigned a value.
"tests/test_cpp.cc", line 221:     Where: While instantiating "gc_allocator<int>::allocate(unsigned long, const void*)".
"tests/test_cpp.cc", line 221:     Where: Instantiated from non-template code.
"./include/gc_allocator.h", line 209: Warning: The variable traits has not yet been assigned a value.
"tests/test_cpp.cc", line 223:     Where: While instantiating "gc_allocator_ignore_off_page<int>::allocate(unsigned long, const void*)".
"tests/test_cpp.cc", line 223:     Where: Instantiated from non-template code.
"tests/test_cpp.cc", line 251: Error: Could not find a match for operator new(unsigned long, GCPlacement).
"tests/test_cpp.cc", line 261: Warning (Anachronism): Formal argument cleanup of type extern "C" void(*)(void*,void*) in call to operator new(unsigned long, GCPlacement, extern "C" void(*)(void*,void*), void*) is being passed void(*)(void*,void*).
"tests/test_cpp.cc", line 272: Error: Could not find a match for operator new(unsigned long, GCPlacement).
2 Error(s) and 3 Warning(s) detected.
gmake[2]: *** [test_cpp.o] Error 2
gmake[2]: Leaving directory `/var/tmp/bdw-gc-7.4.0'

7.4.0: include/gc_allocator.h defines and assigns at the same time

Using Solaris with Sun Studio:

"./include/gc_allocator.h", line 132: Warning: The variable traits has not yet been assigned a value.

This appears to be the same issue as #39

Patching it stops the warning.

build11s64:/var/tmp/bdw-gc-7.4.0 root# diff -ru include/gc_allocator.h.orig include/gc_allocator.h
--- include/gc_allocator.h.orig 2014-05-12 14:14:39.548882685 +1000
+++ include/gc_allocator.h      2014-05-12 14:14:56.545729025 +1000
@@ -125,7 +125,7 @@

   // GC_n is permitted to be 0.  The C++ standard says nothing about what
   // the return value is when GC_n == 0.
-  GC_Tp* allocate(size_type GC_n, const void* = 0) {
+  GC_Tp* allocate(size_type GC_n, const void*) {
     GC_type_traits<GC_Tp> traits;
     return static_cast<GC_Tp *>
             (GC_selective_alloc(GC_n * sizeof(GC_Tp),
@@ -202,7 +202,7 @@

   // GC_n is permitted to be 0.  The C++ standard says nothing about what
   // the return value is when GC_n == 0.
-  GC_Tp* allocate(size_type GC_n, const void* = 0) {
+  GC_Tp* allocate(size_type GC_n, const void*) {
     GC_type_traits<GC_Tp> traits;
     return static_cast<GC_Tp *>
             (GC_selective_alloc(GC_n * sizeof(GC_Tp),
@@ -281,7 +281,7 @@

   // GC_n is permitted to be 0.  The C++ standard says nothing about what
   // the return value is when GC_n == 0.
-  GC_Tp* allocate(size_type GC_n, const void* = 0) {
+  GC_Tp* allocate(size_type GC_n, const void*) {
     return static_cast<GC_Tp*>(GC_MALLOC_UNCOLLECTABLE(GC_n * sizeof(GC_Tp)));
   }

Possible bug in stack walking for win32/x64.

I'm trying to track down a GC problem (via ancient libgc / via ancient mono / via Unity.)

If I have an object that gets stored only in a non-volatile register on x64 (e.g. r12,) and GC is triggered on the same thread, it's getting collected. I see some other platforms push registers on the calling thread (GC_save_regs_in_stack,) but nothing for x64.

I'm not sure if this is a bug, or I'm just misunderstanding something. In the meantime I'm going to try pushing the non-volatile registers for the calling thread.

Cheers

Could you add this code that you (Ivan) gave me in June 2014

Hi Ivan,

You posted some code to the [email protected] mailing list on June 6, 2014 in response to a question I (Christian Schafmeister) asked about walking live objects in the boehm GC space. I've posted a slightly modified version of the code below. Could you add this code (or similar functionality to the Boehm GC)? I've found it tremendously useful and I'm using it in my code (www.github.com/drmeister/clasp).

The code below is in a copy of the boehm library in www.github.com/drmeister/externals-clasp.

Begin code - I put this in reclaim.c

extern attribute((weak)) void GC_callback_reachable_object( GC_word* ptr, size_t sz)
{
printf("Reachable object@%p sz[%lu]\n", ptr, sz);
}

// Added by Christian Schafmeister June 2014
// From Ivan Maidanski and posted to [email protected]
// on June 6, 2014
//
STATIC void GC_mercury_do_enumerate_reachable_objects(struct hblk *hbp,
word dummy)
{
struct hblkhdr * hhdr = HDR(hbp);
size_t sz = hhdr -> hb_sz;
size_t bit_no;
char *p, *plim;

if (GC_block_empty(hhdr)) {
    return;
}

p = hbp->hb_body;
bit_no = 0;
if (sz > MAXOBJBYTES) { /* one big object */
    plim = p;
} else {
    plim = hbp->hb_body + HBLKSIZE - sz;
}
/* Go through all words in block. */
while (p <= plim) {
    if (mark_bit_from_hdr(hhdr, bit_no)) {
        GC_callback_reachable_object((GC_word *)p,
                                             BYTES_TO_WORDS(sz));
    }
    bit_no += MARK_BIT_OFFSET(sz);
    p += sz;
}

}

GC_INNER void GC_mercury_enumerate_reachable_objects(void)
{
GC_ASSERT(GC_callback_reachable_object);
GC_apply_to_all_blocks(GC_mercury_do_enumerate_reachable_objects, (word)0);
}

Test failures on alpine linux

I built on alpine (musl-libc and bash-based) linux. There's some test failures including a segfault. Any advice on how to debug?

================================
   gc 7.4.2: ./test-suite.log
================================

# TOTAL: 15
# PASS:  11
# SKIP:  0
# XFAIL: 0
# FAIL:  4
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: cordtest
==============


FAIL: gctest
============

Switched to incremental mode
Emulating dirty bits with mprotect/signals

FAIL: test_cpp
==============

usage: test_cpp number-of-iterations
Assuming 10 iters
Starting iteration 1

FAIL: disclaim_bench
====================

                        fin. ratio       time/s    time/fin.

PASS: hugetest
PASS: leaktest
./test-driver: line 107: 22132 Segmentation fault      "$@" > $log_file 2>&1
FAIL: cordtest
./test-driver: line 107: 22123 Segmentation fault      "$@" > $log_file 2>&1
FAIL: gctest
PASS: smashtest
PASS: threadleaktest
PASS: initsecondarythread_test
PASS: threadkey_test
PASS: middletest
PASS: subthreadcreate_test
./test-driver: line 107: 22330 Killed                  "$@" > $log_file 2>&1
FAIL: test_cpp
./test-driver: line 107: 23196 Segmentation fault      "$@" > $log_file 2>&1
FAIL: disclaim_bench
PASS: disclaim_test
PASS: staticrootstest
PASS: realloc_test

7.4.0: Makefile.in: ASM_CPP_OPTIONS is gcc specific

The Makefile.in hardcodes the ASM_CPP_OPTIONS to 'extern -Wp,-P -x assembler-with-cpp'. These args don't work with the Sun Studio compiler.

/usr/local/bin/bash ./libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H   -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -I/usr/local/include  -I/usr/local/include -DSCM_API=extern -Wp,-P -x assembler-with-cpp -c src/sparc_mach_dep.S
libtool: compile:  cc -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -I/usr/local/include -I/usr/local/include -DSCM_API=extern -Wp,-P -x assembler-with-cpp -c src/sparc_mach_dep.S  -KPIC -DPIC -o .libs/sparc_mach_dep.o
cc: Warning: illegal option -xassembler-with-cpp

I use this as a work-around when compiling to clear the variable:

perl -pe 's#ASM_CPP_OPTIONS =.*#ASM_CPP_OPTIONS =#' -i Makefile.in

I see you already fixed the src/sparc_mach_dep.lo problem :)

sparc_mach_dep.lo in wrong dir

Building gc 7.4 on Sparc Solaris fails with

libtool: link: `src/sparc_mach_dep.lo' is not a valid libtool object

The problem is that the file is actually in top level (sparc_mach_dep.lo, not under src/sparc_mach_dep.lo). If I manually edit the Makefile and remove src/ from all occurencies of src/sparc_mach_dep.lo, the compilation succeeds.

libcord does not export symbols.

libcord is compiled with -fvisibility=hidden, but no export annotation is provided in cord.h and private/cord_pos.h. As a result "make check" fails, and libcord is not usable.

My libcord-visibility branch should fix it. I changed the gc_config_macros.h to make the corresponding macros useful to cord.h, so we avoid duplicating the compiler-dependent dispatching.

--disable-static influences what's exported

Using the Archlinux package, which passes --disable-static to ./configure, I'm missing in particular GC_push_all_eager.

$ pacman -Qi gc
Name           : gc
Version        : 7.4.2-2
Description    : A garbage collector for C and C++
Architecture   : x86_64
URL            : http://www.hboehm.info/gc/
Licenses       : GPL
Groups         : None
Provides       : None
Depends On     : gcc-libs  libatomic_ops
Optional Deps  : None
Required By    : crystal  guile  inkscape
Optional For   : None
Conflicts With : None
Replaces       : None
Installed Size : 699.00 KiB
Packager       : Jan Alexander Steffens (heftig) <[email protected]>
Build Date     : Thu 11 Sep 2014 11:22:54 PM CEST
Install Date   : Sun 04 Jan 2015 02:03:03 PM CET
Install Reason : Installed as a dependency for another package
Install Script : No
Validated By   : Signature

$ nm -D /usr/lib/libgc.so.1.0.3
[...]
00000000000119e0 T GC_add_roots
000000000022581c D GC_all_interior_pointers
0000000000019340 T GC_allow_register_threads
0000000000237300 B GC_arrays
000000000001a5c0 T GC_atfork_child
000000000001a550 T GC_atfork_parent
000000000001a6e0 T GC_atfork_prepare
00000000000126c0 T GC_base
00000000000184e0 T GC_calloc_explicitly_typed
0000000000013690 T GC_call_with_alloc_lock
0000000000019760 T GC_call_with_gc_active
0000000000013700 T GC_call_with_stack_base
0000000000016ec0 T GC_change_stubborn
000000000000f830 T GC_clear_mark_bit
0000000000011a80 T GC_clear_roots
0000000000012620 T GC_clear_stack
0000000000008140 T GC_collect_a_little
0000000000009b10 T GC_debug_change_stubborn
0000000000009b20 T GC_debug_end_stubborn_change
0000000000009dc0 T GC_debug_free
000000000000cd10 T GC_debug_gcj_malloc
0000000000225488 D GC_debug_header_size
0000000000009950 T GC_debug_malloc
0000000000009b30 T GC_debug_malloc_atomic
0000000000009a70 T GC_debug_malloc_atomic_ignore_off_page
0000000000009d40 T GC_debug_malloc_atomic_uncollectable
00000000000099e0 T GC_debug_malloc_ignore_off_page
000000000000a650 T GC_debug_malloc_replacement
0000000000009b00 T GC_debug_malloc_stubborn
0000000000009cc0 T GC_debug_malloc_uncollectable
0000000000009f20 T GC_debug_realloc
000000000000a660 T GC_debug_realloc_replacement
00000000000098f0 T GC_debug_register_displacement
000000000000a1d0 T GC_debug_register_finalizer
000000000000a530 T GC_debug_register_finalizer_ignore_self
000000000000a2f0 T GC_debug_register_finalizer_no_order
000000000000a410 T GC_debug_register_finalizer_unreachable
0000000000009bc0 T GC_debug_strdup
0000000000009c50 T GC_debug_strndup
00000000000133d0 T GC_disable
000000000000c880 T GC_dlopen
0000000000013750 T GC_do_blocking
0000000000225d68 B GC_dont_expand
00000000002360e8 B GC_dont_gc
00000000002360e4 B GC_dont_precollect
00000000000137a0 T GC_dump
0000000000013370 T GC_enable
0000000000013d90 T GC_enable_incremental
0000000000016eb0 T GC_end_stubborn_change
0000000000013070 T GC_err_printf
0000000000011fd0 T GC_exclude_static_roots
0000000000008730 T GC_expand_hp
000000000000c640 T GC_finalize_all
000000000001b350 T GC_finalized_malloc
00000000002360c8 B GC_finalize_on_demand
00000000002360c0 B GC_finalizer_notifier
00000000002360d0 B GC_find_leak
000000000000e3d0 T GC_free
0000000000225460 D GC_free_space_divisor
0000000000225468 D GC_full_freq
0000000000236000 B GC_gcj_debug_kind
0000000000236004 B GC_gcj_kind
0000000000017230 T GC_gcj_malloc
000000000000ce20 T GC_gcj_malloc_ignore_off_page
0000000000225d88 B GC_gc_no
0000000000008320 T GC_gcollect
0000000000008350 T GC_gcollect_and_unmap
000000000000b000 T GC_general_register_disappearing_link
000000000000ddc0 T GC_generic_malloc
000000000000e760 T GC_generic_malloc_ignore_off_page
000000000000e9a0 T GC_generic_malloc_many
0000000000013310 T GC_get_abort_func
00000000000141a0 T GC_get_all_interior_pointers
00000000000128c0 T GC_get_bytes_since_gc
0000000000014200 T GC_get_dont_expand
00000000000142a0 T GC_get_dont_precollect
00000000000141c0 T GC_get_finalize_on_demand
00000000000140a0 T GC_get_finalizer_notifier
0000000000014110 T GC_get_find_leak
0000000000014300 T GC_get_force_unmap_on_gcollect
00000000000128a0 T GC_get_free_bytes
0000000000014260 T GC_get_free_space_divisor
00000000000142c0 T GC_get_full_freq
0000000000013ea0 T GC_get_gc_no
0000000000012890 T GC_get_heap_size
00000000000128e0 T GC_get_heap_usage_safe
00000000000141e0 T GC_get_java_finalization
0000000000014280 T GC_get_max_retries
0000000000014220 T GC_get_no_dls
0000000000014240 T GC_get_non_gc_bytes
0000000000013fe0 T GC_get_on_heap_resize
0000000000013f20 T GC_get_oom_fn
0000000000015ab0 T GC_get_pages_executable
0000000000013eb0 T GC_get_parallel
00000000000129e0 T GC_get_prof_stats
0000000000012ac0 T GC_get_prof_stats_unsafe
00000000000154b0 T GC_get_push_other_roots
0000000000015230 T GC_get_stack_base
0000000000007510 T GC_get_start_callback
0000000000007350 T GC_get_stop_func
000000000001a880 T GC_get_suspend_signal
000000000001a8a0 T GC_get_thr_restart_signal
00000000000142e0 T GC_get_time_limit
00000000000128d0 T GC_get_total_bytes
00000000000128b0 T GC_get_unmapped_bytes
00000000000072e0 T GC_get_version
0000000000013250 T GC_get_warn_proc
0000000000225d10 B GC_greatest_plausible_heap_addr
00000000000131d0 T GC_ignore_warn_proc
000000000000e980 T GC_incr_bytes_allocd
000000000000e990 T GC_incr_bytes_freed
0000000000015810 T GC_incremental_protection_needs
0000000000013800 T GC_init
000000000001b150 T GC_init_finalized_malloc
000000000000c9d0 T GC_init_gcj_malloc
000000000000c4e0 T GC_invoke_finalizers
0000000000013430 T GC_is_disabled
0000000000012800 T GC_is_heap_ptr
000000000000f890 T GC_is_marked
0000000000015d10 T GC_is_valid_displacement
0000000000225850 D GC_is_valid_displacement_print_proc
0000000000015e00 T GC_is_visible
0000000000225848 D GC_is_visible_print_proc
0000000000225818 D GC_java_finalization
0000000000225448 D GC_least_plausible_heap_addr
0000000000012ed0 T GC_log_printf
0000000000017ff0 T GC_make_descriptor
0000000000017070 T GC_malloc
0000000000017150 T GC_malloc_atomic
000000000000e970 T GC_malloc_atomic_ignore_off_page
000000000000f060 T GC_malloc_atomic_uncollectable
0000000000018140 T GC_malloc_explicitly_typed
0000000000018310 T GC_malloc_explicitly_typed_ignore_off_page
000000000000e960 T GC_malloc_ignore_off_page
000000000000eee0 T GC_malloc_many
0000000000016ea0 T GC_malloc_stubborn
000000000000e230 T GC_malloc_uncollectable
0000000000010a20 T GC_mark_and_push
0000000000225d00 B GC_max_retries
000000000000ef40 T GC_memalign
000000000000b3d0 T GC_move_disappearing_link
000000000000b470 T GC_move_long_link
00000000000134c0 T GC_new_free_list
0000000000013450 T GC_new_free_list_inner
0000000000013580 T GC_new_kind
0000000000013510 T GC_new_kind_inner
0000000000013640 T GC_new_proc
0000000000013600 T GC_new_proc_inner
0000000000236098 B GC_no_dls
0000000000225d90 B GC_non_gc_bytes
000000000000f6e0 T GC_noop1
0000000000225820 D GC_on_abort
0000000000225d20 B GC_on_heap_resize
0000000000225830 D GC_oom_fn
0000000000225d80 B GC_parallel
000000000000f020 T GC_posix_memalign
0000000000015ea0 T GC_post_incr
0000000000015e60 T GC_pre_incr
0000000000012d30 T GC_printf
0000000000019d60 T GC_pthread_cancel
000000000001a0b0 T GC_pthread_create
0000000000019c20 T GC_pthread_detach
0000000000019e10 T GC_pthread_exit
0000000000019af0 T GC_pthread_join
0000000000019180 T GC_pthread_sigmask
0000000000010850 T GC_push_all
0000000000010a00 T GC_push_conditional
0000000000225840 D GC_push_other_roots
000000000000f250 T GC_realloc
0000000000009520 T GC_register_describe_type_fn
000000000000b030 T GC_register_disappearing_link
000000000001b130 T GC_register_disclaim_proc
0000000000014760 T GC_register_displacement
000000000000ba00 T GC_register_finalizer
000000000000ba10 T GC_register_finalizer_ignore_self
000000000000ba20 T GC_register_finalizer_no_order
000000000000ba30 T GC_register_finalizer_unreachable
000000000000aa90 T GC_register_has_static_roots_callback
000000000000b180 T GC_register_long_link
0000000000019ec0 T GC_register_my_thread
0000000000011d20 T GC_remove_roots
0000000000015bc0 T GC_same_obj
0000000000225858 D GC_same_obj_print_proc
00000000000132b0 T GC_set_abort_func
0000000000014120 T GC_set_all_interior_pointers
00000000000141f0 T GC_set_dont_expand
0000000000014290 T GC_set_dont_precollect
00000000000141b0 T GC_set_finalize_on_demand
0000000000014040 T GC_set_finalizer_notifier
0000000000014100 T GC_set_find_leak
00000000000142f0 T GC_set_force_unmap_on_gcollect
0000000000014250 T GC_set_free_space_divisor
00000000000142b0 T GC_set_full_freq
0000000000012410 T GC_set_handle_fork
00000000000141d0 T GC_set_java_finalization
000000000000f7f0 T GC_set_mark_bit
0000000000008580 T GC_set_max_heap_size
0000000000014270 T GC_set_max_retries
0000000000014210 T GC_set_no_dls
0000000000014230 T GC_set_non_gc_bytes
0000000000013f80 T GC_set_on_heap_resize
0000000000013ec0 T GC_set_oom_fn
0000000000015aa0 T GC_set_pages_executable
00000000000154a0 T GC_set_push_other_roots
00000000000074b0 T GC_set_start_callback
00000000000072f0 T GC_set_stop_func
000000000001a840 T GC_set_suspend_signal
000000000001a860 T GC_set_thr_restart_signal
00000000000142d0 T GC_set_time_limit
00000000000131f0 T GC_set_warn_proc
000000000000c4d0 T GC_should_invoke_finalizers
0000000000012870 T GC_size
00000000002360f0 B GC_stackbottom
0000000000018980 T GC_start_mark_threads
000000000000f3c0 T GC_strdup
000000000000f420 T GC_strndup
0000000000019410 T GC_thread_is_registered
0000000000225458 D GC_time_limit
0000000000008310 T GC_try_to_collect
000000000000b060 T GC_unregister_disappearing_link
000000000000b1b0 T GC_unregister_long_link
0000000000019970 T GC_unregister_my_thread
0000000000225ce8 B GC_use_entire_heap
[...]

Removing --disable-static and rebuilding the package I get

$ nm -D /usr/lib/libgc.so.1.0.3
[...]
0000000000022e60 T GC_acquire_mark_lock
000000000023f6c8 B GC_active_count
0000000000020330 T GC_add_ext_descriptor
000000000001d390 T GC_add_map_entry
000000000001a520 T GC_add_roots
000000000001a400 T GC_add_roots_inner
0000000000012a00 T GC_add_smashed
0000000000011840 T GC_add_to_black_list_normal
00000000000118d0 T GC_add_to_black_list_stack
000000000000f170 T GC_add_to_fl
0000000000010dc0 T GC_add_to_heap
000000000000fdb0 T GC_adj_bytes_allocd
000000000023f6a0 B GC_all_bottom_indices
000000000023f698 B GC_all_bottom_indices_end
000000000022ef3c D GC_all_interior_pointers
0000000000240220 B GC_allocate_ml
000000000000f810 T GC_allochblk
000000000000f360 T GC_allochblk_nth
00000000000165c0 T GC_alloc_large
00000000000166c0 T GC_alloc_large_and_clear
00000000000114e0 T GC_allocobj
0000000000016560 T GC_alloc_reclaim_list
0000000000021ee0 T GC_allow_register_threads
000000000022d7c8 D GC_aobjfreelist_ptr
0000000000016200 T GC_apply_to_all_blocks
000000000001a910 T GC_approx_sp
000000000023f988 B GC_arobjfreelist
000000000023f9b8 B GC_array_kind
0000000000020ba0 T GC_array_mark_proc
000000000023f998 B GC_array_mark_proc_index
0000000000240840 B GC_arrays
0000000000022f60 T GC_atfork_child
0000000000022ef0 T GC_atfork_parent
0000000000023070 T GC_atfork_prepare
000000000022d7b8 D GC_auobjfreelist_ptr
000000000023f9a0 B GC_avail_descr
000000000001b0f0 T GC_base
000000000022ebb8 D GC_black_list_spacing
0000000000011740 T GC_bl_init
00000000000116b0 T GC_bl_init_no_interiors
000000000001ee20 T GC_block_empty
000000000001ee30 T GC_block_nearly_full
0000000000019c30 T GC_block_was_dirty
0000000000271120 B GC_bm_table
000000000001d160 T GC_build_fl
000000000001d0d0 T GC_build_fl2
000000000001d110 T GC_build_fl4
000000000001d000 T GC_build_fl_clear2
000000000001d060 T GC_build_fl_clear4
000000000023f6b8 B GC_bytes_allocd_tmp
000000000023f968 B GC_bytes_found
00000000000210c0 T GC_calloc_explicitly_typed
000000000001c2c0 T GC_call_with_alloc_lock
0000000000022280 T GC_call_with_gc_active
000000000001c330 T GC_call_with_stack_base
000000000001faf0 T GC_change_stubborn
0000000000011e00 T GC_check_annotated_obj
0000000000021880 T GC_check_finalizer_nested
000000000022f410 B GC_check_heap
0000000000012a30 T GC_check_heap_block
0000000000011c20 T GC_check_heap_proc
0000000000012ad0 T GC_check_leaked
000000000000fe00 T GC_clear_a_few_frames
00000000000116a0 T GC_clear_bl
000000000001f710 T GC_clear_fl_links
0000000000010200 T GC_clear_fl_marks
00000000000181f0 T GC_clear_hdr_marks
0000000000018320 T GC_clear_mark_bit
00000000000183b0 T GC_clear_marks
000000000001a5c0 T GC_clear_roots
000000000001b090 T GC_clear_stack
000000000001b010 T GC_clear_stack_inner
0000000000010b60 T GC_collect_a_little
0000000000010800 T GC_collect_a_little_inner
000000000022eb90 D GC_collect_at_heapsize
000000000023f9e0 B GC_collecting
00000000000181d0 T GC_collection_in_progress
0000000000011220 T GC_collect_or_expand
000000000000ebe0 T GC_compute_large_free_bytes
000000000001a290 T GC_compute_root_size
000000000001acc0 T GC_cond_register_dynamic_libraries
000000000001f740 T GC_continue_reclaim
00000000000117d0 T GC_copy_bl
000000000022d780 D GC_copyright
0000000000023c20 T GC_core_finalized_malloc
0000000000015680 T GC_core_gcj_malloc
0000000000016c30 T GC_core_malloc
0000000000016af0 T GC_core_malloc_atomic
000000000022ef48 D GC_current_warn_proc
000000000023f7b0 B GC_data_start
0000000000012440 T GC_debug_change_stubborn
0000000000012450 T GC_debug_end_stubborn_change
00000000000126f0 T GC_debug_free
00000000000157e0 T GC_debug_gcj_malloc
000000000023f778 B GC_debugging_started
000000000022ebc8 D GC_debug_header_size
0000000000011c10 T GC_debug_invoke_finalizer
0000000000012280 T GC_debug_malloc
0000000000012460 T GC_debug_malloc_atomic
00000000000123a0 T GC_debug_malloc_atomic_ignore_off_page
0000000000012670 T GC_debug_malloc_atomic_uncollectable
0000000000012310 T GC_debug_malloc_ignore_off_page
0000000000012fe0 T GC_debug_malloc_replacement
0000000000012430 T GC_debug_malloc_stubborn
00000000000125f0 T GC_debug_malloc_uncollectable
0000000000012000 T GC_debug_print_heap_obj_proc
0000000000012870 T GC_debug_realloc
0000000000012ff0 T GC_debug_realloc_replacement
0000000000012210 T GC_debug_register_displacement
0000000000012ba0 T GC_debug_register_finalizer
0000000000012ed0 T GC_debug_register_finalizer_ignore_self
0000000000012cb0 T GC_debug_register_finalizer_no_order
0000000000012dc0 T GC_debug_register_finalizer_unreachable
00000000000124f0 T GC_debug_strdup
0000000000012580 T GC_debug_strndup
000000000001e790 T GC_default_is_valid_displacement_print_proc
000000000001e7e0 T GC_default_is_visible_print_proc
000000000001b860 T GC_default_on_abort
000000000001ae00 T GC_default_oom_fn
0000000000011630 T GC_default_print_heap_obj_proc
000000000001d510 T GC_default_push_other_roots
000000000001e740 T GC_default_same_obj_print_proc
000000000022ebb0 D GC_default_stop_func
000000000001bd70 T GC_default_warn_proc
000000000022f418 B GC_deficit
00000000000217e0 T GC_delete_gc_thread
0000000000021780 T GC_delete_thread
000000000022f5a0 B GC_describe_type_fns
0000000000020970 T GC_descr_obj_size
000000000001fc40 T GC_destroy_thread_local
000000000001e230 T GC_dirty_init
000000000023f7a0 B GC_dirty_maintained
000000000001bfd0 T GC_disable
000000000001ef50 T GC_disclaim_and_reclaim
000000000001f280 T GC_disclaim_and_reclaim_or_free_small_block
000000000022ec00 D GC_dl_hashtbl
00000000000152f0 T GC_dlopen
000000000001c380 T GC_do_blocking
00000000000221b0 T GC_do_blocking_inner
0000000000018ea0 T GC_do_local_mark
000000000022f448 B GC_dont_expand
000000000023f768 B GC_dont_gc
000000000023f764 B GC_dont_precollect
00000000000191e0 T GC_do_parallel_mark
00000000000205c0 T GC_double_descr
000000000001c3d0 T GC_dump
0000000000014480 T GC_dump_finalization
0000000000014400 T GC_dump_finalization_links
000000000000ed50 T GC_dump_regions
000000000023f754 B GC_dump_regularly
000000000023f9a8 B GC_ed_size
000000000001bf60 T GC_enable
000000000001c9f0 T GC_enable_incremental
000000000001fae0 T GC_end_stubborn_change
0000000000014d80 T GC_enqueue_all_finalizers
000000000023f990 B GC_eobjfreelist
000000000001bc20 T GC_err_printf
000000000001bc00 T GC_err_puts
000000000023f708 B GC_excl_table_entries
000000000001ab30 T GC_exclude_static_roots
000000000001aa20 T GC_exclude_static_roots_inner
000000000001ae10 T GC_exit_check
0000000000011190 T GC_expand_hp
0000000000010fe0 T GC_expand_hp_inner
000000000023f9bc B GC_explicit_kind
000000000023f9c0 B GC_explicit_typing_initialized
000000000023f9b0 B GC_ext_descriptors
000000000001af00 T GC_extend_size_map
000000000022f3d0 B GC_fail_count
000000000001d4f0 T GC_fault_handler
000000000023f788 B GC_fault_handler_lock
0000000000014590 T GC_finalize
0000000000015090 T GC_finalize_all
0000000000023ae0 T GC_finalized_disclaim
0000000000240740 B GC_finalized_kind
0000000000023d70 T GC_finalized_malloc
000000000023f978 B GC_finalized_objfreelist
000000000023f650 B GC_finalize_now
000000000023f748 B GC_finalize_on_demand
000000000023f740 B GC_finalizer_notifier
0000000000015a80 T GC_find_header
000000000023f750 B GC_find_leak
000000000023f74c B GC_findleak_delay_free
000000000001dca0 T GC_find_limit
000000000001dbb0 T GC_find_limit_with_bound
00000000000102b0 T GC_finish_collection
0000000000013300 T GC_FirstDLOpenedLinkMap
000000000023f6e0 B GC_first_nonempty
000000000023f960 B GC_fl_builder_count
000000000022f3d8 B GC_fo_entries
000000000023f658 B GC_fo_head
000000000023f73c B GC_force_unmap_on_gcollect
0000000000016f00 T GC_free
000000000000f080 T GC_free_block_ending_at
000000000022efe0 B GC_free_bytes
000000000000f960 T GC_freehblk
0000000000017130 T GC_free_inner
000000000022eba0 D GC_free_space_divisor
000000000022eba8 D GC_full_freq
000000000023f680 B GC_gcj_debug_kind
000000000023f670 B GC_gcjdebugobjfreelist
0000000000015430 T GC_gcj_fake_mark_proc
000000000023f684 B GC_gcj_kind
000000000001fe50 T GC_gcj_malloc
0000000000015900 T GC_gcj_malloc_ignore_off_page
000000000023f688 B GC_gcj_malloc_initialized
000000000023f678 B GC_gcjobjfreelist
000000000022f468 B GC_gc_no
0000000000010d70 T GC_gcollect
0000000000010da0 T GC_gcollect_and_unmap
0000000000013980 T GC_general_register_disappearing_link
0000000000021f00 T GC_generic_lock
00000000000168c0 T GC_generic_malloc
00000000000172a0 T GC_generic_malloc_ignore_off_page
0000000000016730 T GC_generic_malloc_inner
0000000000016880 T GC_generic_malloc_inner_ignore_off_page
00000000000174d0 T GC_generic_malloc_many
0000000000017d80 T GC_generic_or_special_malloc
000000000001bef0 T GC_get_abort_func
000000000001ce90 T GC_get_all_interior_pointers
000000000001b2f0 T GC_get_bytes_since_gc
000000000001cef0 T GC_get_dont_expand
000000000001cf90 T GC_get_dont_precollect
000000000001d900 T GC_get_file_len
000000000001ceb0 T GC_get_finalize_on_demand
000000000001cd60 T GC_get_finalizer_notifier
000000000001cde0 T GC_get_find_leak
000000000000f230 T GC_get_first_part
000000000001cff0 T GC_get_force_unmap_on_gcollect
000000000001b2d0 T GC_get_free_bytes
000000000001cf50 T GC_get_free_space_divisor
000000000001cfb0 T GC_get_full_freq
000000000001cb10 T GC_get_gc_no
000000000001b2c0 T GC_get_heap_size
000000000001b310 T GC_get_heap_usage_safe
000000000001ced0 T GC_get_java_finalization
000000000001dd60 T GC_get_main_stack_base
000000000001d9c0 T GC_get_maps
000000000001d980 T GC_get_maps_len
000000000001cf70 T GC_get_max_retries
000000000001cf10 T GC_get_no_dls
000000000001cf30 T GC_get_non_gc_bytes
00000000000219a0 T GC_get_nprocs
000000000001cc80 T GC_get_on_heap_resize
000000000001cba0 T GC_get_oom_fn
000000000001e6f0 T GC_get_pages_executable
000000000001cb20 T GC_get_parallel
000000000001b410 T GC_get_prof_stats
000000000001b560 T GC_get_prof_stats_unsafe
000000000001e0b0 T GC_get_push_other_roots
000000000001de10 T GC_get_stack_base
000000000000fee0 T GC_get_start_callback
000000000000fd40 T GC_get_stop_func
0000000000023220 T GC_get_suspend_signal
0000000000023240 T GC_get_thr_restart_signal
000000000001cfd0 T GC_get_time_limit
000000000001b300 T GC_get_total_bytes
000000000001b2e0 T GC_get_unmapped_bytes
000000000000fcc0 T GC_get_version
000000000001be10 T GC_get_warn_proc
000000000022f3f0 B GC_greatest_plausible_heap_addr
00000000000135d0 T GC_grow_table
000000000023f738 B GC_handle_fork
0000000000011c90 T GC_has_other_debug_info
000000000022f620 B GC_has_static_roots
000000000023f800 B GC_have_errors
000000000000eba0 T GC_hblk_fl_from_blocks
000000000022f1e0 B GC_hblkfreelist
0000000000015af0 T GC_header_cache_miss
000000000023f6cc B GC_helper_count
0000000000019340 T GC_help_marker
000000000023f6d0 B GC_help_wanted
00000000000134e0 T GC_ignore_self_finalize_mark_proc
000000000001bd80 T GC_ignore_warn_proc
000000000022f4c8 B GC_incomplete_normal_bl
000000000022f4b8 B GC_incomplete_stack_bl
00000000000174b0 T GC_incr_bytes_allocd
00000000000174c0 T GC_incr_bytes_freed
000000000022f464 B GC_incremental
000000000001e440 T GC_incremental_protection_needs
000000000001c430 T GC_init
0000000000020800 T GC_init_explicit_typing
0000000000023b30 T GC_init_finalized_malloc
0000000000015460 T GC_init_gcj_malloc
0000000000015ea0 T GC_init_headers
000000000001d480 T GC_initialize_offsets
00000000000183f0 T GC_initiate_gc
000000000001dcb0 T GC_init_linux_data_start
0000000000022120 T GC_init_parallel
000000000001aea0 T GC_init_size_map
000000000001fba0 T GC_init_thread_local
00000000000213d0 T GC_inner_start_routine
0000000000015fe0 T GC_install_counts
0000000000015f20 T GC_install_header
000000000023f9e4 B GC_in_thread_creation
0000000000018460 T GC_invalidate_mark_state
0000000000014f30 T GC_invoke_finalizers
0000000000011940 T GC_is_black_listed
000000000001c040 T GC_is_disabled
000000000022f41c B GC_is_full_gc
000000000001b230 T GC_is_heap_ptr
000000000023f728 B GC_is_initialized
0000000000018380 T GC_is_marked
000000000001e970 T GC_is_valid_displacement
000000000022ef70 D GC_is_valid_displacement_print_proc
000000000001ea70 T GC_is_visible
000000000022ef68 D GC_is_visible_print_proc
000000000022ef38 D GC_java_finalization
0000000000240760 B GC_jmp_buf
000000000022ef30 D GC_large_alloc_warn_interval
000000000022efc0 B GC_large_alloc_warn_suppressed
000000000023f820 B GC_leaked
000000000022eb88 D GC_least_plausible_heap_addr
000000000001dd30 T GC_linux_main_stack_base
000000000022ebe0 D GC_ll_hashtbl
0000000000021f90 T GC_lock
000000000022ef20 D GC_log
000000000001ba70 T GC_log_printf
0000000000021830 T GC_lookup_thread
0000000000020630 T GC_make_array_descriptor
0000000000012b70 T GC_make_closure
0000000000020c20 T GC_make_descriptor
00000000000205f0 T GC_make_sequence_descriptor
000000000001fca0 T GC_malloc
000000000001fd80 T GC_malloc_atomic
00000000000174a0 T GC_malloc_atomic_ignore_off_page
0000000000017bc0 T GC_malloc_atomic_uncollectable
0000000000020d80 T GC_malloc_explicitly_typed
0000000000020f20 T GC_malloc_explicitly_typed_ignore_off_page
0000000000017490 T GC_malloc_ignore_off_page
0000000000017a50 T GC_malloc_many
000000000001fad0 T GC_malloc_stubborn
0000000000016d40 T GC_malloc_uncollectable
0000000000019600 T GC_mark_and_push
0000000000019800 T GC_mark_and_push_stack
0000000000018500 T GC_mark_from
0000000000019410 T GC_mark_init
0000000000018f90 T GC_mark_local
000000000023f6c0 B GC_mark_no
0000000000019eb0 T GC_mark_some
000000000023f6e8 B GC_mark_stack_size
000000000023f6d8 B GC_mark_stack_too_small
000000000023f6dc B GC_mark_state
00000000000214b0 T GC_mark_thread
000000000001ff60 T GC_mark_thread_local_fls_for
0000000000021530 T GC_mark_thread_local_free_lists
0000000000271220 B GC_mark_threads
000000000022f3e8 B GC_max_heapsize
000000000022f3e0 B GC_max_retries
0000000000010680 T GC_maybe_gc
0000000000017ab0 T GC_memalign
0000000000013d50 T GC_move_disappearing_link
0000000000013c50 T GC_move_disappearing_link_inner
0000000000013e10 T GC_move_long_link
000000000022f438 B GC_n_attempts
000000000022f45c B GC_need_full_gc
0000000000240204 B GC_need_to_lock
000000000000fb80 T GC_never_stop_func
000000000001c0d0 T GC_new_free_list
000000000001c060 T GC_new_free_list_inner
000000000001d230 T GC_new_hblk
000000000001c1a0 T GC_new_kind
000000000001c130 T GC_new_kind_inner
000000000001c260 T GC_new_proc
000000000001c220 T GC_new_proc_inner
0000000000021710 T GC_new_thread
000000000001a980 T GC_next_exclusion
00000000000162a0 T GC_next_used_block
000000000022f3f8 B GC_n_heap_sects
000000000022ec18 D GC_n_kinds
000000000023f804 B GC_n_leaked
000000000022ec1c D GC_n_mark_procs
000000000023f718 B GC_no_dls
000000000022f470 B GC_non_gc_bytes
000000000022f428 B GC_non_gc_bytes_at_gc
00000000000181c0 T GC_noop1
00000000000181b0 T GC_noop6
0000000000240828 B GC_noop_sink
0000000000013440 T GC_normal_finalize_mark_proc
0000000000023090 T GC_notify_all_builder
0000000000023100 T GC_notify_all_marker
0000000000015150 T GC_notify_or_invoke_finalizers
000000000022ef80 D GC_nprocs
000000000023f6f0 B GC_n_rescuing_pages
000000000001f550 T GC_n_set_marks
000000000022f4e0 B GC_n_smashed
0000000000013430 T GC_null_finalize_mark_proc
0000000000011a40 T GC_number_stack_black_listed
000000000023f6d4 B GC_objects_are_marked
000000000022d7d0 D GC_objfreelist_ptr
000000000022ec20 D GC_obj_kinds
000000000023f790 B GC_old_bus_handler
000000000023f648 B GC_old_dl_entries
000000000023f640 B GC_old_ll_entries
000000000022f4d0 B GC_old_normal_bl
000000000023f798 B GC_old_segv_handler
000000000023f78c B GC_old_segv_handler_used_si
000000000022f4c0 B GC_old_stack_bl
000000000022ef40 D GC_on_abort
000000000022f400 B GC_on_heap_resize
000000000022ef50 D GC_oom_fn
000000000023f7b8 B GC_pages_executable
000000000023f7a8 B GC_page_size
000000000001e680 T GC_page_was_dirty
000000000022f460 B GC_parallel
000000000001b6e0 T GC_parse_mem_size_arg
0000000000021ef0 T GC_pause
0000000000017b80 T GC_posix_memalign
000000000001eb10 T GC_post_incr
000000000001ead0 T GC_pre_incr
00000000000163a0 T GC_prev_block
000000000001e700 T GC_print_address_map
000000000001eb50 T GC_print_all_errors
000000000022f408 B GC_print_all_smashed
00000000000120f0 T GC_print_all_smashed_proc
000000000023f758 B GC_print_back_height
000000000001f5b0 T GC_print_block_descr
000000000001f630 T GC_print_block_list
000000000001b8d0 T GC_printf
0000000000015260 T GC_print_finalization_stats
000000000001f6b0 T GC_print_free_list
000000000000ec30 T GC_print_hblkfreelist
000000000022ebc0 D GC_print_heap_obj
0000000000010ef0 T GC_print_heap_sects
0000000000011ea0 T GC_print_obj
0000000000012030 T GC_print_smashed_obj
000000000001a2e0 T GC_print_static_roots
000000000023f75c B GC_print_stats
0000000000011a90 T GC_promote_black_lists
000000000001e460 T GC_protect_heap
0000000000022760 T GC_pthread_cancel
0000000000022a40 T GC_pthread_create
0000000000022680 T GC_pthread_detach
00000000000227e0 T GC_pthread_exit
00000000000225b0 T GC_pthread_join
0000000000021d20 T GC_pthread_sigmask
0000000000019420 T GC_push_all
00000000000199c0 T GC_push_all_eager
0000000000019a30 T GC_push_all_stack
00000000000233c0 T GC_push_all_stacks
000000000001ac50 T GC_push_all_stack_sections
0000000000020a10 T GC_push_complex_descriptor
00000000000195e0 T GC_push_conditional
000000000001abc0 T GC_push_conditional_with_exclusions
000000000001a950 T GC_push_current_stack
0000000000013580 T GC_push_finalizer_structures
000000000001ac90 T GC_push_gc_structures
0000000000019a40 T GC_push_marked
0000000000019ca0 T GC_push_next_marked
0000000000019d10 T GC_push_next_marked_dirty
0000000000019df0 T GC_push_next_marked_uncollectable
0000000000019990 T GC_push_one
000000000022ef60 D GC_push_other_roots
000000000001acf0 T GC_push_regs_and_stack
000000000001ad00 T GC_push_roots
0000000000019490 T GC_push_selected
00000000000216d0 T GC_push_thread_structures
000000000023f700 B GC_push_typed_structures
0000000000020010 T GC_push_typed_structures_proc
0000000000019b50 T GC_push_unconditionally
000000000023f760 B GC_quiet
000000000001e640 T GC_read_dirty
0000000000017dd0 T GC_realloc
000000000001a740 T GC_rebuild_root_index
000000000001f7b0 T GC_reclaim_all
000000000001f320 T GC_reclaim_block
000000000001f080 T GC_reclaim_check
000000000001ee60 T GC_reclaim_clear
000000000023f730 B GC_reclaimed_bytes_before_gc
000000000001f130 T GC_reclaim_generic
000000000001f1f0 T GC_reclaim_small_nonempty_block
000000000001f910 T GC_reclaim_unconditionally_marked
000000000001ef00 T GC_reclaim_uninit
000000000001ded0 T GC_register_data_segments
0000000000011e90 T GC_register_describe_type_fn
00000000000139b0 T GC_register_disappearing_link
00000000000136d0 T GC_register_disappearing_link_inner
0000000000023b10 T GC_register_disclaim_proc
000000000001d330 T GC_register_displacement
000000000001d2e0 T GC_register_displacement_inner
0000000000013370 T GC_register_dynamic_libraries
00000000000131c0 T GC_register_dynamic_libraries_dl_iterate_phdr
0000000000013000 T GC_register_dynlib_callback
00000000000143b0 T GC_register_finalizer
00000000000143c0 T GC_register_finalizer_ignore_self
0000000000013ed0 T GC_register_finalizer_inner
00000000000143d0 T GC_register_finalizer_no_order
00000000000143e0 T GC_register_finalizer_unreachable
0000000000013420 T GC_register_has_static_roots_callback
0000000000013b00 T GC_register_long_link
00000000000131b0 T GC_register_main_static_data
0000000000022860 T GC_register_my_thread
0000000000021e80 T GC_register_my_thread_inner
0000000000022e70 T GC_release_mark_lock
0000000000023160 T GC_remove_allowed_signals
00000000000218d0 T GC_remove_all_threads_but_me
0000000000016160 T GC_remove_counts
000000000000ef50 T GC_remove_from_fl_at
00000000000160e0 T GC_remove_header
000000000001e0c0 T GC_remove_protection
000000000001a6b0 T GC_remove_root_at_pos
000000000001a880 T GC_remove_roots
000000000001a820 T GC_remove_roots_inner
000000000001a7d0 T GC_remove_tmp_roots
000000000001d890 T GC_repeat_read
000000000001db80 T GC_reset_fault_handler
0000000000021860 T GC_reset_finalizer_nested
0000000000023130 T GC_restart_handler
00000000002406a0 B GC_retry_signals
0000000000018dd0 T GC_return_mark_stack
000000000023f710 B GC_root_size
000000000001a390 T GC_roots_present
000000000001e830 T GC_same_obj
000000000022ef78 D GC_same_obj_print_proc
0000000000015c50 T GC_scratch_alloc
000000000001be80 T GC_set_abort_func
000000000001cdf0 T GC_set_all_interior_pointers
000000000001db40 T GC_set_and_save_fault_handler
000000000001cee0 T GC_set_dont_expand
000000000001cf80 T GC_set_dont_precollect
000000000001cea0 T GC_set_finalize_on_demand
000000000001ccf0 T GC_set_finalizer_notifier
000000000001cdd0 T GC_set_find_leak
0000000000010190 T GC_set_fl_marks
000000000001cfe0 T GC_set_force_unmap_on_gcollect
000000000001cf40 T GC_set_free_space_divisor
000000000001cfa0 T GC_set_full_freq
000000000001ae70 T GC_set_handle_fork
0000000000018290 T GC_set_hdr_marks
000000000001cec0 T GC_set_java_finalization
00000000000182e0 T GC_set_mark_bit
0000000000010fd0 T GC_set_max_heap_size
000000000001cf60 T GC_set_max_retries
000000000001cf00 T GC_set_no_dls
000000000001cf20 T GC_set_non_gc_bytes
000000000001cc10 T GC_set_on_heap_resize
000000000001cb30 T GC_set_oom_fn
000000000001e6d0 T GC_set_pages_executable
000000000001db00 T GC_setpagesize
000000000001e0a0 T GC_set_push_other_roots
000000000000fe70 T GC_set_start_callback
000000000000fcd0 T GC_set_stop_func
00000000000231e0 T GC_set_suspend_signal
0000000000023200 T GC_set_thr_restart_signal
000000000001cfc0 T GC_set_time_limit
0000000000022d20 T GC_setup_mark_lock
000000000001db70 T GC_setup_temporary_fault_handler
000000000001bda0 T GC_set_warn_proc
000000000000fe10 T GC_should_collect
0000000000014f10 T GC_should_invoke_finalizers
0000000000018490 T GC_signal_mark_stack_overflow
000000000022ef88 D GC_sig_suspend
000000000022ef84 D GC_sig_thr_restart
000000000001b2a0 T GC_size
000000000022f500 B GC_smashed
000000000000f2b0 T GC_split_block
000000000023f770 B GC_stackbottom
000000000022f420 B GC_start_call_back
00000000000121c0 T GC_start_debugging
0000000000012170 T GC_start_debugging_inner
0000000000021580 T GC_start_mark_threads
000000000001f9b0 T GC_start_reclaim
00000000000214a0 T GC_start_routine
0000000000022990 T GC_start_rtn_prepare_thread
000000000022f440 B GC_start_time
00000000000237c0 T GC_start_world
000000000022ef24 D GC_stderr
000000000022ef28 D GC_stdout
0000000000018d40 T GC_steal_mark_stack
00000000002406b0 B GC_stop_count
0000000000023890 T GC_stop_init
000000000000ff50 T GC_stopped_mark
0000000000023620 T GC_stop_world
0000000000011d70 T GC_store_debug_info
0000000000011d10 T GC_store_debug_info_inner
0000000000017f40 T GC_strdup
0000000000017fa0 T GC_strndup
00000000002712a0 B GC_suspend_ack_sem
0000000000023550 T GC_suspend_all
0000000000023380 T GC_suspend_handler
0000000000023260 T GC_suspend_handler_inner
0000000000022510 T GC_thread_exit_proc
0000000000021fc0 T GC_thread_is_registered
0000000000000000 B GC_thread_key
000000000023fa00 B GC_threads
0000000000021ab0 T GC_thr_init
0000000000240200 B GC_thr_initialized
000000000022eb98 D GC_time_limit
000000000000fc20 T GC_timeout_stop_func
000000000022f4b0 B GC_total_stack_black_listed
000000000022f430 B GC_total_stacksize
0000000000010d60 T GC_try_to_collect
0000000000010c00 T GC_try_to_collect_general
0000000000010980 T GC_try_to_collect_inner
0000000000020020 T GC_typed_mark_proc
000000000023f99c B GC_typed_mark_proc_index
000000000001e060 T GC_unix_get_mem
000000000001def0 T GC_unix_mmap_get_mem
000000000001e010 T GC_unix_sbrk_get_mem
00000000000117f0 T GC_unpromote_black_lists
00000000000134d0 T GC_unreachable_finalize_mark_proc
00000000000139e0 T GC_unregister_disappearing_link
0000000000013b30 T GC_unregister_long_link
0000000000022460 T GC_unregister_my_thread
0000000000021e40 T GC_unregister_my_thread_inner
000000000022d7c0 D GC_uobjfreelist_ptr
000000000022f450 B GC_used_heap_size_after_full
000000000022f3c8 B GC_use_entire_heap
00000000000247c8 R GC_version
0000000000022f80 T GC_wait_builder
0000000000022030 T GC_wait_for_gc_completion
0000000000022fc0 T GC_wait_for_reclaim
00000000000230c0 T GC_wait_marker
00000000000164a0 T GC_with_callee_saves_pushed
00000000002406a8 B GC_world_is_stopped
000000000022f458 B GC_world_stopped
000000000001b7b0 T GC_write
000000000001d520 T GC_write_fault_handler
[...]

Notice how GC_push_all_eager appeared.

Archlinux applies this patch. While I doubt it's related, I didn't verify.

Affected by this through downstream at crystal-lang/crystal@f54463d
Downstream issue: crystal-lang/crystal#837

configure: line 17503: syntax error near unexpected token `ATOMIC_OPS'

configure: line 17503: syntax error near unexpected token `ATOMIC_OPS,'
configure: line 17503: `   PKG_CHECK_MODULES(ATOMIC_OPS, atomic_ops, ,'

This happens when I run ./configure in Linux and Windows using Autoconf 2.69.

This occurs on the master branch and on the 7.4.2 release.

I am able to get a makefile by using the make -f Makefile.direct test command, but when running make then it gives me:

^^^^Starting command^^^^
tests/test.o:test.c:(.rdata$.refptr._bss_start__[.refptr._bss_start__]+0x0): undefined reference to `_bss_start__'
tests/test.o:test.c:(.rdata$.refptr._data_start__[.refptr._data_start__]+0x0): undefined reference to `_data_start__'
tests/test.o:test.c:(.rdata$.refptr._bss_end__[.refptr._bss_end__]+0x0): undefined reference to `_bss_end__'
tests/test.o:test.c:(.rdata$.refptr._data_end__[.refptr._data_end__]+0x0): undefined reference to `_data_end__'
collect2: error: ld returned 1 exit status
Makefile.direct:394: recipe for target 'gctest' failed
make: *** [gctest] Error 1

Build failed on NetBSD/sparc64, Makefile problem

Hi,
When building with ./configure && make on NetBSD/sparc64 the build failed with:

make[1]: don't know how to make sparc_mach_dep.lo. Stop

This fixed the problem:
gc-7.4.2$ mv src/* .

(Why are the sparc assembler files alone in the src subdirectory?)