From tlumley at u.washington.edu  Sat Jan  1 01:08:37 2005
From: tlumley at u.washington.edu (Thomas Lumley)
Date: Sat Jan  1 01:08:47 2005
Subject: [Rd] optim/vmmin and R_alloc
In-Reply-To: <20041231103325.GA5410@tal.stat.umu.se>
References: <20041230155513.GA22178@tal.stat.umu.se>
	<Pine.A41.4.61b.0412300757350.11816@homer11.u.washington.edu>
	<20041230185913.GA1735@tal.stat.umu.se>
	<Pine.A41.4.61b.0412301418350.219480@homer09.u.washington.edu>
	<20041231103325.GA5410@tal.stat.umu.se>
Message-ID: <Pine.A41.4.61b.0412311551030.53274@homer12.u.washington.edu>

On Fri, 31 Dec 2004, [iso-8859-1] G?ran Brostr?m wrote:
>
> Regarding 2., I tried the combination vmaxget + Calloc + vmaxset, ie, I
> began my function with vmax = vmaxget() and ended it with
> vmaxset(vmax). The point with this is that you can free all allocated
> memory with one call instead of repeated calls to Free. This seemed to work
> well; however, it is undocumented, and may well be completely wrong.

I think it's completely wrong.  Free is just a wrapper for free() from the 
C library, and vmaxset() works only on the R heap and contains no calls to 
free(), so they shouldn't intersect at all. The memory leak will 
happen outside the R heap, and it may be less obvious there as long as you 
aren't short of virtual memory.

Calloc/Free still follow the basic C rule that you must call Free exactly 
once on each pointer returned by Calloc.  The fact that Free sets its 
argument to NULL reduces somewhat the likelihood of damage from calling 
Free more than once, but only reduces it, since Free can't set other 
copies of the pointer to NULL.

 	-thomas

[Rd] optim/vmmin and R_alloc
Thomas Lumley