From hin-tak.leung at cimr.cam.ac.uk  Mon Feb 26 11:51:45 2007
From: hin-tak.leung at cimr.cam.ac.uk (Hin-Tak Leung)
Date: Mon, 26 Feb 2007 10:51:45 +0000
Subject: [Rd] R/C++/memory leaks
In-Reply-To: <39CFDB8F-918C-48FB-9A6D-D8055D828C13@ic.ac.uk>
References: <39CFDB8F-918C-48FB-9A6D-D8055D828C13@ic.ac.uk>
Message-ID: <45E2BBC1.10201@cimr.cam.ac.uk>

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.

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



[Rd] R/C++/memory leaks
Hin-Tak Leung