[Mono-devel-list] Re: [Gc] Boehm GC interaction with other libraries

[eric lindvall]

So there isn't anything in the calls I listed that would strike you as
possibly leading to memory leaks/corruption?

Are there any defines I can use to help track down where the corruption is
coming from?

e.


On Wed, 26 Nov 2003, Boehm, Hans wrote:

> > From: gc-admin at napali.hpl.hp.com [mailto:gc-admin at napali.hpl.hp.com] On Behalf Of eric lindvall
> > Sent: Wednesday, November 26, 2003 3:03 PM
> 
> > I have a few questions about how code that uses the Boehm GC interacts
> > with libraries that were not compiled against the Boehm GC
> > library/headers.
> > 
> > I am seeing some odd behaviour when using Platform Invoke 
> > (P/Invoke) in
> > Mono to invoke native libraries from Mono. From what I can 
> > see, it seems
> > like there is some sort of memory corruption going on.
> > 
> > The native library makes use of:
> >  - malloc(), free()
> >  - pthread_create()
> >  - pthread_cond_init(), pthread_cond_signal(), pthread_cond_wait()
> >  - sem_init(), sem_wait(), sem_post()
> >  - msgsnd(), msgrcv()
> > 
> > The questions I have are:
> > 
> > 1. Is memory that I allocate with malloc() in libraries that were not
> > compiled against boehm seen by the garbage collector? (will it ever be
> > collected out from under me?)
> Assuming the GC library was not compiled with -DREDIRECT_MALLOC,
> memory allocated with malloc is neither collected nor traced.  The
> malloced objects should not disappear out from under you.  The collectable
> objects they refer to may.  (The collector tries not to trace malloced
> memory.  Under win32, it sometimes ends up tracing it anyway, which is
> benign for correctness, but not performance.  It can
> never collect memory allocated through the system malloc.)
> > 
> > 2. Will boehm just "ignore" any threads that were created by
> > a version of pthread_create() that was not wrapped by boehm?
> I believe that's correct (for the collector, not me personally :-) ),
> provided the collector is initialized from the main thread,
> and you are not on a platform on which the collector can enuumerate
> all threads.  (Currently that happens for win32 with the collector
> in its own dll.)  The collector currently needs to know about the
> main thread.  (It currently has no way to find the stack base of
> an arbitrary thread, and hence "knows" that it is initialized from the
> main thread, so that it can register the initializing thread.)
> 
> Note that if the ignored threads change pointers in/to the garbage-collected
> heap, all bets are off.
> > 
> > 3. Will anything bad happen if the libraries that I invoke use
> > pthread_cond_wait()?
> If the collector knows about it, I suspect that the pthread_cond_wait() call may
> terminate after the collector stops and restarts the thread.  But that's OK, since
> the pthread spec allows that behavior anyway.
> 
> Hans