This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: scm_must_malloc and memory leaking?


forcer <forcer@mindless.com> writes:

> On Mon, Apr 19, 1999 at 04:18:54PM -0230, Greg Harvey wrote:
> >forcer <forcer@mindless.com> writes:
> >> 	f = scm_must_malloc(sizeof(some_struct));
> >> 	f->data = scm_must_malloc(size);
> >> 
> >> and there won't be enough free memory for the second
> >> scm_must_malloc even after gc, the allocated memory in f is
> >> lost and won't be free'd. Is that true? 
> >
> >Nope.
> 
> That's quite interesting, and i'd like to know how Guile does
> this. I looked at the sourcecode to scm_must_malloc, and i don't
> see how the data stored in f could be freed.
> 
> Recalling what will happen in the scenario described above:
>  - f = scm_must_malloc(sizeof(some_struct));
>    scm_must_malloc calls malloc and returns the pointer. It
>    doesn't keep track of it in any way except to increase the
>    scm_mallocated global variable (i just rechecked the source on
>    this)
>  - f->data = scm_must_malloc(size);
>    scm_must_malloc calls malloc and notices that it couldn't get
>    enough memory. So it calls gc, and after that malloc again.
>    Still, not enough free memory, so it throws an exception,
>    which also bypasses our function.
> 
> So after this, the memory pointed to by f is not referenced
> anywhere.
> 
> Even if it would, the GC would have no way to tell wether it's
> used anywhere, since it surely doesn't contain a SCM value.
> 
> So you say that still it will be freed, and i wonder how. I'm
> sorry if my first question didn't describe the problem properly.

Sorry, I didn't read the first message well (it's been one of those
days... I meant nope in that f will not be free'd, so it should've
been yep ;)). This memory will be lost if this is the case; there's
not all that a generic type of malloc could do about it; the
alternatives are using something like the scm_malloc implementation
(in mallocs.c); you could also set up a catch for this (or a
dynamic-wind, I think... I'm not as familiar as I should be with that
bit of guile).  The entire point is probably moot, though, since an
inability to allocate is usually pretty fatal (so you probably would
like to set up a catch for a memory error, so that you can clean
things up). 



-- 
Greg