[gclist] a puzzle, Boehm gc compatiblity with freebsd?

[Boehm, Hans]

> -----Original Message-----
> From: Rob Rodgers [mailto:knave@acm.org]
> 
> [Problem with mixing malloc and GC_MALLOC when using collector as leak
detector.]
>
> Is this expected behavior?  It seems like this would make 
> life quite difficult
> for those of us who want to use the GC to verify programs 
> that are linked with
> binary modules or libraries that malloc internally..
> 
It's expected behavior when the collector is built this way.  On some
platforms it is possible to instead override malloc at the linker level.  I
would guess that on X86 freebsd, the leak detector will be more robust if
you build with -DREDIRECT_MALLOC=GC_debug_malloc_replacement (using the old
Makefile).  There are some potential problems with this:

1) On platforms like win32, link-time replacement of malloc in the presence
of dynamic libraries requires a lot more work, which I haven't done.  I
think the Geodesic Systems people are experts here.

2) You lose the file name and line number information which is normally
passed implicitly and recorded in the object when you call GC_MALLOC.  (On
some platforms you can largely make up for this by saving partial call
stacks in the object.  I don't think this currently works on FreeBSD.  But
since it works on Linux, that probably wouldn't be hard to fix.)

3) On some platforms this fails for multithreaded apps, since malloc is
called before the thread system is fully initialized, and the multithreaded
collector needs the thread system.

4) In some rare cases you end with infinite recursion or deadlocks with
collector logging turned on.  Malloc actually calls GC_malloc calls sprintf
calls malloc ...

Hans