[Gc] A bug in multi-threaded application

Hans Boehm Hans.Boehm at hp.com
Sat Oct 8 22:39:48 PDT 2005


The collector is currently known not to trave thread local variables
reliably.  If a thread local points to the collected heap, you also
need to add that pointer to a global data structure.  For 7.0, I believe
this is the only thing preventing LD_PRELOAD-based malloc interception
on Linux, so it would be nice to fix this.  But tracking these down
seems nontrivial.

Hans

On Mon, 3 Oct 2005, Manuel Serrano wrote:

> Hello there,
>
> I have a problem with the version 6.6 and 6.5 (I have not tested
> earlier versions of the collector). In multi-threaded applications, I
> have the impression that the collector does not trace the data
> contained in the specific variables of the main thread.
>
> Here is a source code that illustrates this problem:
>
> -----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----
> #include <pthread.h>
> #include <gc.h>
> #include <stdio.h>
>
> #define SPECIFIC_MAIN 1
>
> void *l;
> static pthread_key_t bgldenv_key;
>
> void allocate( int i, int c ) {
>    void *l2;
>
>    while( 1 ) {
>       l2 = GC_malloc( 10 );
>
>       printf( "l=%p\n", l2 );
>
>       if( c && (pthread_getspecific( bgldenv_key ) == l2) ) {
> 	 fprintf( stderr, "GOT IT....%p\n", l2 );
> 	 exit( 0 );
>       }
>       if( i == 0 ) {
> 	 GC_gcollect();
> 	 i = 1000;
>       }
>    }
> }
>
> void *run() {
>    pthread_attr_t a;
>
>    pthread_attr_init( &a );
>
>    pthread_attr_setdetachstate( &a, PTHREAD_CREATE_DETACHED );
>
>
> #if SPECIFIC_MAIN
>    allocate( 1000, 0 );
> #else
>    foo();
>    allocate( 1000, 1 );
> #endif
> }
>
> int foo() {
>    l = GC_malloc( 10 );
>    pthread_key_create( &bgldenv_key, 0 );
>    l = GC_malloc( 10 );
>    pthread_setspecific( bgldenv_key, l );
> }
>
> int main() {
>    pthread_t thread;
>
> #if SPECIFIC_MAIN
>    foo();
> #endif
>
>    printf( "l=%p\n", l );
>    l = 0;
>
>    GC_gcollect();
>
>    pthread_create( &thread, 0L, &run, 0 );
>
> #if SPECIFIC_MAIN
>    allocate( 1000, 1 );
> #else
>    allocate( 1000, 0 );
> #endif
>
>    pthread_join( thread, 0 );
> }
> -----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----
>
> Turn the definition of SPECIFIC_MAIN to 0 and it works (apparently).
>
> Is there any reason for the collector not to trace the main thread specific
> area? Do I misunderstand something?
>
> Many thanks in advance for your help.
>
> --
> Manuel
>
> uname -a:
> Linux redrock 2.6.12 #3 SMP Tue Jun 21 08:51:51 CEST 2005 i686 Intel(R) Xeon(TM)  CPU 3.00GHz GenuineIntel GNU/Linux
>
> gcc -v:
> Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/specs
> Configured with: /var/tmp/portage/gcc-3.3.6/work/gcc-3.3.6/configure --prefix=/u sr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3.6 --includedir=/usr/lib/gcc-lib/i 686-pc-linux-gnu/3.3.6/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3 .3.6 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.6/man --infodir=/usr/sha re/gcc-data/i686-pc-linux-gnu/3.3.6/info --with-gxx-include-dir=/usr/lib/gcc-lib /i686-pc-linux-gnu/3.3.6/include/g++-v3 --host=i686-pc-linux-gnu --build=i686-pc -linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-syst em-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --dis able-multilib --disable-libgcj --enable-languages=c,c++,f77 --enable-shared --en able-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
> Thread model: posix
> gcc version 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)
>
> epm -qa | grep libc:
> glibc-2.3.5-r1
>
> _______________________________________________
> 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