[Gc] GC and dynamic libraries

Joris van der Hoeven vdhoeven at texmacs.org
Wed Jun 16 13:20:07 PDT 2004


Hi Hans,

On Tue, 15 Jun 2004, Boehm, Hans wrote:
> 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.

It probably is, but it is strange that this only happens in
combination with dynamic linking.

> 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.

Nobody does:

---------------------------------------------------
(gdb) run
Starting program:
/home/vdhoeven/distr/Mathemagix-0.1.37-src/src/target/mmx_shell.bin
[New Thread 8192 (LWP 2973)]
------------------------------------------------------------
|:*)            Welcome to Mathemagix 0.1.37            (*:|
|      (c) 2001--2004  by Joris van der Hoeven et al.      |
| This software falls under the GNU General Public License |
|         It comes without any warranty whatsoever         |
------------------------------------------------------------
1>
Program received signal SIGINT, Interrupt.
[Switching to Thread 8192 (LWP 2973)]
0x420cdb44 in read () from /lib/i686/libc.so.6
(gdb) break malloc
Breakpoint 1 at 0x4000d5c6
(gdb) cont
Continuing.
use "demo2"
2> polynomial(1,2,3)
1 + 2 * x + 3 * x ^ 2: (Polynomial~ (Integer~))
(1, 2, 3): 1 () (~, (Cross~ (Integer~, Integer~, Integer~)))
3> polynomial(1,2,3)

Program received signal SIGSEGV, Segmentation fault.
0x0811d834 in mmx::table_rep::contains(mmx::generic) (this=0x819dc90)
    at types/generic.hh:101
101       inline generic& operator [] (int i) { return rep->Access (i); }
---------------------------------------------------

> There ars some more detailed debugging techniques near the end of
>
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/debugging.html

I will take a look at that.

> 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.

In the above example, I don't really use any functions from the STL
(apart from std::ostream). I thought that including new_gc_alloc.h
would make GC the default allocator, but if I understand you right,
that is not so, and I should explicitly give the GC allocator as
an argument to each template?

I also heep wondering how it is possible that I only
encounter problems with the dynamically linked version.



More information about the Gc mailing list