[M3devel] malloc/free from Modula-3?

[Daniel Alejandro Benavides D.]

Hi all:
the only thing you need to keep control as of CM3 is concerned is the modula-3 free calls equals the number of news, that is, if not is runtime error, but it isn't vice versa, if you broke this then you are obviously unsafely corrupted, but as far as the process is concerned it will be growing in time the heap until termination. If this is exacerbated then you will run out of memory either in Modula-3 or C which is dangerous, so this tells you why the scheduler must be aware of this calls, at least that's my rationale.
You are right I think there is a unixdb client program that crashes that can't be build in cm3 as it asks to provide their external implementation function calls so you can't declare external calls on your own, you need like compile it too, which is very strange, though my memories about this are very diffuse.

Thanks in advance
--- El lun, 18/4/11, Mika Nystrom <mika at async.caltech.edu> escribió:

> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] malloc/free from Modula-3?
> Para: "Tony Hosking" <hosking at cs.purdue.edu>
> CC: m3devel at elegosoft.com
> Fecha: lunes, 18 de abril, 2011 11:10
> 
> Tony Hosking writes:
> >I suspect the problem is re-entrance to the library.
> Should you be =
> >disabling user thread switching somewhere?
> 
> I suspect the same.  That's why I asked what the
> "rules" are
> for calling malloc and free.  I notice that the m3core
> code has
> Scheduler.DisableSwitching around all calls to malloc but
> not around calls
> to free.  Why would one be unsafe and the other
> safe?  It is always free
> that my program hangs up on by the way.  Surrounding
> all "suspicious" calls
> in my code with Scheduler.DisableSwitching doesn't solve
> the problem, as
> far as I can tell.
> 
> I am further suspecting that my problem is related to my
> having linked the
> program with -pthread.  I am also guessing that this
> is the same reason
> you can't link FreeBSD user threads programs with -pthread:
> namely that if
> you go reentrantly into the pthread malloc library some
> code assumes 
> the two invocations are from separate threads and locks up
> if they are from
> the same thread.  That's my guess anyhow.  But
> that doesn't explain why
> I've never seen any malloc/free problems on FreeBSD without
> -pthread.
> (I don't think I have, anyhow.)
> 
>     Mika
> 
>