From tlumley at u.washington.edu  Mon Feb 26 22:42:25 2007
From: tlumley at u.washington.edu (Thomas Lumley)
Date: Mon, 26 Feb 2007 13:42:25 -0800 (PST)
Subject: [Rd] R/C++/memory leaks
In-Reply-To: <45E2BBC1.10201@cimr.cam.ac.uk>
References: <39CFDB8F-918C-48FB-9A6D-D8055D828C13@ic.ac.uk>
	<45E2BBC1.10201@cimr.cam.ac.uk>
Message-ID: <Pine.LNX.4.64.0702261340440.3337@homer22.u.washington.edu>

On Mon, 26 Feb 2007, Hin-Tak Leung wrote:

> Read the help page of gc(). You need to run it with reset=TRUE for
> the usage to drop back to original. i.e. gc(reset=TRUE). gc() on its
> own doesn't quite do what you think it would do.

This is almost completely incorrect (apart from the advice to read the 
help page).  The setting for reset= has absolutely no effect on R's memory 
use. It just clears the internal variable that has kept track of the 
highest memory use so far.

 	-thomas


> Ernest Turro wrote:
>> Dear all,
>>
>> I have wrapped a C++ function in an R package. I allocate/deallocate
>> memory using C++ 'new' and 'delete'. In order to allow user
>> interrupts without memory leaks I've moved all the delete statements
>> required after an interrupt to a separate C++ function freeMemory(),
>> which is called using on.exit() just before the .C() call.
>>
>> I am concerned about the following. In square brackets you see R's
>> total virtual memory use (VIRT in `top`):
>>
>> 1) Load library and data [178MB] (if I run gc(), then [122MB])
>> 2) Just before .C [223MB]
>> 3) Just before freeing memory [325MB]
>> 4) Just after freeing memory [288MB]
>> 5) After running gc() [230MB]
>>
>> So although the freeMemory function works (frees 37MB), R ends up
>> using 100MB more after the function call than before it. ls() only
>> returns the data object so no new objects have been added to the
>> workspace.
>>
>> Do any of you have any idea what could be eating this memory?
>>
>> Many thanks,
>>
>> Ernest
>>
>> PS: it is not practical to use R_alloc et al because C++ allocation/
>> deallocation involves constructors/destructors and because the C++
>> code is also compiled into a standalone binary (I would rather avoid
>> maintaining two separate versions).
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

Thomas Lumley			Assoc. Professor, Biostatistics
tlumley at u.washington.edu	University of Washington, Seattle



[Rd] R/C++/memory leaks
Thomas Lumley