[Gc] Bugreport: Segfault/Infinite loop in version 6.6 on FreeBSD 5.5
klaas at kite.ping.de
Tue Jul 4 16:53:51 PDT 2006
I would like to report a bug in version 6.6 of the garbage collector
on FreeBSD 5.5. I checked the file recent_changes in the distribution
directory, it does not appear that this one has been fixed in 6.7.
Essentially there are two problems that may or may not be related:
a) Simply linking a program against the GC library (-lgc) causes it to
loop indefinitely, never doing anything. The test program used is
the standard "hello world" program, so there is no explicit call to
malloc() anywhere in the program.
b) Linking the same program both against the garbage collector and the
pthread library causes a segfault during the program loading stage,
i.e. before main() is called.
A session transcript demonstrating the issues follows.
% uname -a
FreeBSD line 5.5-STABLE FreeBSD 5.5-STABLE #2: Wed Jun 28 07:52:48 EDT 2006 root at line:/usr/obj/usr/src/sys/LINE i386
% pkg_info | grep boehm
boehm-gc+threaded+redirect-6.6_3 Garbage collection and memory leak detection for C and C++
% gcc --version
gcc (GCC) 3.4.2 [FreeBSD] 20040728
Copyright (C) 2004 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.
% cat main.c
int main( int argc, char* argv )
% gcc -c -g main.c
% gcc -o x main.o
% gcc -o x -L/usr/local/lib -lgc -lpthread main.o
zsh: segmentation fault (core dumped) ./x
% gcc -o x -L/usr/local/lib -lgc main.o
[The program would just hang at this point, so it was interrupted.]
Running the last binary under gdb and checking the stack trace after
hitting the interrupt key shows that the program interrupted in
nanosleep(2), called from GC_lock(), called from GC_malloc().
Inspection of the core dump from the binary linked against both gc and
pthread shows that it segfaulted in sched_yield(), also called from
Note that I came across this problem while investigating a build issue
on another package, there is a fair chance that I am not using the gc
library correctly in this test program.
As shown in the session transcript, I am using the "plain vanilla"
version of the library as it is installed by the relevant port.
I apologize if I am missing something obvious, but I concluded that if
the hello world program shows a problem then it is very likely that
the library is the source of the problem, not the test program.
I will be happy to assist the investigation process if required.
More information about the Gc