[Gc] Bugreport: Segfault/Infinite loop in version 6.6 on FreeBSD 5.5

Boehm, Hans hans.boehm at hp.com
Wed Jul 5 13:09:56 PDT 2006


It looks like the GC library was built with threads + malloc
redirection?

I would be amazed if that worked correctly on FreeBSD.  And I would
expect it to misbehave about as you described.  I'm not sure whether
that combination works with 6.7 on any platforms.

With luck, it now works on Linux, but only for gc7.0.  And getting it to
work required significant surgery.  There are typically several issues:

1) The threads library may call malloc during its initialization.
GC_malloc more or less expects threads and especially locks to work,
which they won't in this state.  (7.0 deals with this by not locking
until a second thread has been created.)

2) The C/C++ runtime tends to store pointers to malloced memory in weird
places, e.g. in memory mmapped by the dynamic loader for its own data.

My recommendation is to

a) Don't build with malloc redirection, or

b) Use 7.0 CVS (which may require some debugging on FreeBSD).

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Klaas Teschauer
> Sent: Tuesday, July 04, 2006 4:54 PM
> To: mmcg at cs.monash.edu.au; gc at napali.hpl.hp.com
> Subject: [Gc] Bugreport: Segfault/Infinite loop in version 
> 6.6 on FreeBSD 5.5
> 
> Hi,
> 
> 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 
> boehm-gc+threaded+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
> #include <stdio.h>
> 
> int main( int argc, char* argv[] )
> {
>   printf("Hello World!\n");
>   return 0;
> }
> 
> % gcc -c -g main.c
> % gcc -o x main.o
> % ./x
> Hello World!
> % gcc -o x -L/usr/local/lib -lgc -lpthread main.o % ./x
> zsh: segmentation fault (core dumped)  ./x % gcc -o x 
> -L/usr/local/lib -lgc  main.o % ./x ^C [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 GC_lock()/GC_malloc().
> 
> 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.
> 
> Best Regards,
> 
>      Klaas
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 



More information about the Gc mailing list