[Gc] GC and dynamic libraries

Boehm, Hans hans.boehm at hp.com
Tue Jun 15 15:45:55 PDT 2004


This is almost certainly not the problem I was alluding to.  It looks like
it's crashing in your code, not the collector.  It looks like
something was collected prematurely.

My guess is that some objects are allocated through the system allocator,
and hence not traced.  This results in the referenced objects being
prematurely collected.

You might try running this under gdb, typing "break malloc", and watching
who still calls the system malloc.

There ars some more detailed debugging techniques near the end of

http://www.hpl.hp.com/personal/Hans_Boehm/gc/debugging.html

Just including new_gc_alloc.h isn't likely to have much effect.  It only
defines STL allocators; you still have to use them in your code.  But if you
make use of the default STL allocator, and put garbage-collected objects in
STL containers, I would have also expected the statically linked version
to fail.

Hans



> -----Original Message-----
> From: Joris van der Hoeven [mailto:vdhoeven at texmacs.org]
> Sent: Tuesday, June 15, 2004 2:43 AM
> To: Boehm, Hans
> Cc: 'Joris van der Hoeven'; gc at napali.hpl.hp.com; Gabriel Dos Reis
> Subject: RE: [Gc] GC and dynamic libraries
> 
> 
> 
> Hi Hans,
> 
> Thanks for your detailed reply.
> 
> On Mon, 14 Jun 2004, Boehm, Hans wrote:
> > On Linux at least, there shouldn't be an issue with this.  On a
> > sufficiently recent Linux system, the collector uses dl_iterate_phdr
> > to enumerate the static data sections associated with all dynamic
> > libraries, and then treats those as roots.
> 
> I use a redhat 9.0 system; I assume this is sufficiently recent.
> 
> > I think there was an earlier bug report suggesting that if 
> the collector
> > itself resides in a dynamic library, on some Linux distributions, it
> > effectively sees a value of _end that refers to the dynamic library
> > and not the main program.  This will cause a crash.  I 
> believe that by
> > ELF rules, this is incorrect and thus a linker problem.  But I don't
> > think it was ever completely resolved.  And I don't think it occurs
> > in most distributions.
> 
> The collector is linked to the main program, not the dynamic library,
> so that should not be the problem.
> 
> > To track this down further, please post the (relevant sections of)
> > the backtrace at the time of the SIGSEGV that caused the crash, the
> > output of GC_dump() when called from the debugger at that point, and
> > the contents of /proc/<pid>/maps of the dying process, as 
> it's stopped
> > by the debugger.
> 
> I also have been looking a bit further into the problem myself,
> and read more carefully the notes for using gc in combination 
> with C++.
> Maybe I did something wrong there, but then it is strange that
> I only run into problems when using dynamic libraries.
> Let me describe more precisely what I did:
> 
> 1) Originally, I just performed a ./configure, make, make install
>    in order to install gc, include gc.h and declared global new
>    and delete operators as follows:
> 
> inline void* operator new (register size_t sz) { return 
> GC_MALLOC (sz); }
> inline void* operator new[] (register size_t sz) { return 
> GC_MALLOC (sz); }
> inline void operator delete (register void* ptr) { (void) ptr; }
> inline void operator delete[] (register void* ptr) { (void) ptr; }
> 
>    Notice that the main executable was compiled using
> 
> g++ -rdynamic [... lots of *.o ...] -lgc -lreadline -ltermcap 
> -ldl -o target/mmx_shell.bin
> 
>    and the dynamic library was compiled using
> 
> g++ -fPIC -shared -I/home/vdhoeven/mathemagix/src/include 
> simple.cpp -o /home/vdhoeven/mathemagix/src/lib/mmx-simple.so
> 
>    All .cc files first include the header file with the 
> new/delete redefinitions.
> 
> 2) I now retried using ./configure --enable-cplusplus, then including
>    gc/new_gc_alloc.h and also declaring the global new and delete
>    as above. This still does not work, but maybe I am still doing
>    something wrong...
> 
> 3) Here is some of the information you asked. I do not know how to run
>    GC_dump from the debugger (I do not use gdb very much). I tried
>    GC_dump() and GC_dump, but that does not work. What should I do?
> 
> (gdb) bt
> #0  0x0806edae in print_lisp (arg_1=@0xbffff0a0, arg_2={rep = 
> 0x81b483c}) at evaluator/Evaluate/simple.cc:290
> #1  0x08078256 in print_lisp<simple_inst_1> (out=@0x8135eec, 
> z={_M_real = {rep = 0x81b483c}, _M_imag = {rep = 0x81b4854}}) 
> at /usr/local/gcc/include/c++/3.3.2/complex:129
> #2  0x40050a06 in FUN_27 (g={rep = 0x819d048}) at simple.cpp:785
> #3  0x08060bcc in mmx::evaluator_rep::kw_conv_apply_2() 
> (this=0x812e080) at types/list.hh:106
> #4  0x08066a6b in mmx::evaluator_rep::loop() (this=0x812e080) 
> at evaluator/keyword.hh:35
> #5  0x08066b65 in mmx::evaluator_rep::evaluate(mmx::generic) 
> (this=0x812e080) at evaluator/Evaluate/evaluate.cc:135
> #6  0x08064ee4 in mmx::evaluator_rep::display_one(mmx::value) 
> (this=0xbffff0a0) at types/list.hh:62
> #7  0x0806575e in mmx::evaluator_rep::display(mmx::value) 
> (this=0x812e080) at evaluator/Evaluate/display.cc:88
> #8  0x0806731b in mmx_display () at evaluator/evaluator.hh:67
> #9  0x0805ea9c in output () at types/value.hh:26
> #10 0x0805eded in main (argc=1, argv=0xbffff4a4) at 
> evaluator/Main/mmx_shell.cc:137
> #11 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
> 
> [vdhoeven at alcazar distr]$ more /proc/18631/maps
> 08048000-08106000 r-xp 00000000 03:05 799755     
> /home/vdhoeven/distr/Mathemagix-0.1.37-src/src/target/mmx_shell.bin
> 08106000-0811d000 rw-p 000bd000 03:05 799755     
> /home/vdhoeven/distr/Mathemagix-0.1.37-src/src/target/mmx_shell.bin
> 0811d000-081b5000 rwxp 00000000 00:00 0
> 40000000-40012000 r-xp 00000000 03:03 1338244    /lib/ld-2.2.93.so
> 40012000-40013000 rw-p 00012000 03:03 1338244    /lib/ld-2.2.93.so
> 40013000-40014000 rw-p 00000000 00:00 0
> 40014000-40031000 r-xp 00000000 03:03 2417977    
> /usr/local-3.3.2/lib/libgc.so.1.0.2
> 40031000-40035000 rw-p 0001d000 03:03 2417977    
> /usr/local-3.3.2/lib/libgc.so.1.0.2
> 40035000-40043000 rw-p 00000000 00:00 0
> 40043000-4005a000 r-xp 00000000 03:05 1451041    
> /home/vdhoeven/distr/Mathemagix-0.1.37-src/lib/mmx-simple.so
> 4005a000-4005d000 rw-p 00017000 03:05 1451041    
> /home/vdhoeven/distr/Mathemagix-0.1.37-src/lib/mmx-simple.so
> 4005d000-40084000 r-xp 00000000 03:03 375617     
> /usr/lib/libreadline.so.4.3
> 40084000-40088000 rw-p 00026000 03:03 375617     
> /usr/lib/libreadline.so.4.3
> 40088000-40089000 rw-p 00000000 00:00 0
> 40089000-4008c000 r-xp 00000000 03:03 1338318    
> /lib/libtermcap.so.2.0.8
> 4008c000-4008d000 rw-p 00002000 03:03 1338318    
> /lib/libtermcap.so.2.0.8
> 4008d000-4008f000 r-xp 00000000 03:03 1338257    /lib/libdl-2.2.93.so
> 4008f000-40090000 rw-p 00001000 03:03 1338257    /lib/libdl-2.2.93.so
> 40090000-4012c000 r-xp 00000000 03:03 2009809    
> /usr/local-3.3.2/gcc-3.3.2/lib/libstdc++.so.5.0.5
> 4012c000-40141000 rw-p 0009c000 03:03 2009809    
> /usr/local-3.3.2/gcc-3.3.2/lib/libstdc++.so.5.0.5
> 40141000-40146000 rw-p 00000000 00:00 0
> 40146000-40167000 r-xp 00000000 03:03 2382726    
> /lib/i686/libm-2.2.93.so
> 40167000-40168000 rw-p 00021000 03:03 2382726    
> /lib/i686/libm-2.2.93.so
> 40168000-4016f000 r-xp 00000000 03:03 2009771    
> /usr/local-3.3.2/gcc-3.3.2/lib/libgcc_s.so.1
> 4016f000-40170000 rw-p 00007000 03:03 2009771    
> /usr/local-3.3.2/gcc-3.3.2/lib/libgcc_s.so.1
> 40170000-40171000 rw-p 00000000 00:00 0
> 40171000-4017e000 r-xp 00000000 03:03 2382728    
> /lib/i686/libpthread-0.10.so
> 4017e000-40181000 rw-p 0000d000 03:03 2382728    
> /lib/i686/libpthread-0.10.so
> 40181000-401a1000 rw-p 00000000 00:00 0
> 401a1000-40368000 r--p 00000000 03:03 489602     
> /usr/lib/locale/locale-archive
> 42000000-42126000 r-xp 00000000 03:03 2382724    
> /lib/i686/libc-2.2.93.so
> 42126000-4212b000 rw-p 00126000 03:03 2382724    
> /lib/i686/libc-2.2.93.so
> 4212b000-4212f000 rw-p 00000000 00:00 0
> bfffa000-c0000000 rwxp ffffb000 00:00 0
> 08106000-0811d000 rw-p 000bd000 03:05 799755     
> /home/vdhoeven/distr/Mathemagix-0.1.37-src/src/target/mmx_shell.bin
> 0811d000-081b5000 rwxp 00000000 00:00 0
> 40000000-40012000 r-xp 00000000 03:03 1338244    /lib/ld-2.2.93.so
> 40012000-40013000 rw-p 00012000 03:03 1338244    /lib/ld-2.2.93.so
> 40013000-40014000 rw-p 00000000 00:00 0
> 40014000-40031000 r-xp 00000000 03:03 2417977    
> /usr/local-3.3.2/lib/libgc.so.1.0.2
> 40031000-40035000 rw-p 0001d000 03:03 2417977    
> /usr/local-3.3.2/lib/libgc.so.1.0.2
> 40035000-40043000 rw-p 00000000 00:00 0
> 40043000-4005a000 r-xp 00000000 03:05 1451041    
> /home/vdhoeven/distr/Mathemagix-0.1.37-src/lib/mmx-simple.so
> 4005a000-4005d000 rw-p 00017000 03:05 1451041    
> /home/vdhoeven/distr/Mathemagix-0.1.37-src/lib/mmx-simple.so
> 4005d000-40084000 r-xp 00000000 03:03 375617     
> /usr/lib/libreadline.so.4.3
> 40084000-40088000 rw-p 00026000 03:03 375617     
> /usr/lib/libreadline.so.4.3
> 40088000-40089000 rw-p 00000000 00:00 0
> 40089000-4008c000 r-xp 00000000 03:03 1338318    
> /lib/libtermcap.so.2.0.8
> 4008c000-4008d000 rw-p 00002000 03:03 1338318    
> /lib/libtermcap.so.2.0.8
> 4008d000-4008f000 r-xp 00000000 03:03 1338257    /lib/libdl-2.2.93.so
> 4008f000-40090000 rw-p 00001000 03:03 1338257    /lib/libdl-2.2.93.so
> 40090000-4012c000 r-xp 00000000 03:03 2009809    
> /usr/local-3.3.2/gcc-3.3.2/lib/libstdc++.so.5.0.5
> 4012c000-40141000 rw-p 0009c000 03:03 2009809    
> /usr/local-3.3.2/gcc-3.3.2/lib/libstdc++.so.5.0.5
> 40141000-40146000 rw-p 00000000 00:00 0
> 40146000-40167000 r-xp 00000000 03:03 2382726    
> /lib/i686/libm-2.2.93.so
> 40167000-40168000 rw-p 00021000 03:03 2382726    
> /lib/i686/libm-2.2.93.so
> 40168000-4016f000 r-xp 00000000 03:03 2009771    
> /usr/local-3.3.2/gcc-3.3.2/lib/libgcc_s.so.1
> 4016f000-40170000 rw-p 00007000 03:03 2009771    
> /usr/local-3.3.2/gcc-3.3.2/lib/libgcc_s.so.1
> 40170000-40171000 rw-p 00000000 00:00 0
> 40171000-4017e000 r-xp 00000000 03:03 2382728    
> /lib/i686/libpthread-0.10.so
> 4017e000-40181000 rw-p 0000d000 03:03 2382728    
> /lib/i686/libpthread-0.10.so
> 40181000-401a1000 rw-p 00000000 00:00 0
> 401a1000-40368000 r--p 00000000 03:03 489602     
> /usr/lib/locale/locale-archive
> 42000000-42126000 r-xp 00000000 03:03 2382724    
> /lib/i686/libc-2.2.93.so
> 42126000-4212b000 rw-p 00126000 03:03 2382724    
> /lib/i686/libc-2.2.93.so
> 4212b000-4212f000 rw-p 00000000 00:00 0
> bfffa000-c0000000 rwxp ffffb000 00:00 0
> 
> Thanks for your help, Joris
> 
> > > -----Original Message-----
> > > From: gc-bounces at napali.hpl.hp.com
> > > [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Joris 
> van der Hoeven
> > > Sent: Thursday, June 10, 2004 4:09 AM
> > > To: gc at napali.hpl.hp.com
> > > Cc: Gabriel Dos Reis; vdhoeven at texmacs.org
> > > Subject: [Gc] GC and dynamic libraries
> > >
> > >
> > >
> > > Hi,
> > >
> > > This may be a frequently asked question: do I need to do
> > > something special
> > > in order to use GC in combination with dynamically loaded 
> libraries?
> > >
> > > Indeed, I am writing an interpreter which uses GC as its
> > > garbage collector,
> > > and which should be able to dynamically load third party
> > > libraries using
> > > an instruction from within the interpreter. I work under GNU/Linux
> > > and used the commands
> > >
> > > 	g++ -fPIC -c -I/home/vdhoeven/mathemagix/src/include/
> > > mmx-simple.cc -o mmx-simple.o
> > > 	g++ -lgc -fPIC -shared mmx-simple.o -o mmx-simple.so
> > >
> > > in order to compile my .so. I also used the code below for
> > > the dynamic linking from within the interpreter:
> > >
> > > ---------------------------------------------------
> > > void
> > > evaluator_rep::kw_use_2 () {
> > >   CHECK_SYNC (MMX_USE);
> > >   // Input: (use_2, module_name, cont, ...)
> > >   string name= as_string (V (car (rem)));
> > >   string lib = string("mmx-"*name*".so");
> > >   string rout= "init_" * name; // attention to mangling by C+
> > >   char* _lib = as_charp (lib);
> > >   char* _rout= as_charp (rout);
> > >
> > >   void* handle= dlopen (_lib, RTLD_LAZY | RTLD_GLOBAL);
> > >   if (handle == NULL) {
> > >     error (car (trace), dlerror ());
> > >     // cerr << "Dynamic library " << lib << " did not open\n";
> > >     return;
> > >   }
> > >   else {
> > >     void* f= dlsym (handle, _rout);
> > >     if (f == NULL) {
> > >       error (car (trace), "Symbol " * rout * " not defined in
> > > " * lib);
> > >       return;
> > >     }
> > >     else {
> > >       void (*init) (void)= (void (*) (void)) f;
> > >       init ();
> > >     }
> > >   }
> > >   cur= cadr (rem);
> > >   rem= cons (VAL_NONE, cddr (rem));
> > >   // Output: (cont, none, ...)
> > >   trace= cdr (trace);
> > > }
> > > ---------------------------------------------------
> > >
> > > When doing so, I obtain a segmentation fault after a while.
> > > When I statically link the same code, everything works fine.
> > > So I probably used a wrong linking option or should I tell
> > > the GC about dynamically linked libraries?
> > >
> > > Thanks for your time, Joris
> > >
> > > -----------------------------------------------------------
> > > Joris van der Hoeven <vdhoeven at texmacs.org>
> > > http://www.texmacs.org: GNU TeXmacs scientific text editor
> > > http://www.math.u-psud.fr/~vdhoeven: personal homepage
> > > -----------------------------------------------------------
> > >
> > > _______________________________________________
> > > 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