[Rcpp-devel] Incomplete Heap memory freeing under R
edd at debian.org
Thu Mar 31 21:33:36 CEST 2016
On 31 March 2016 at 22:15, rosterma at abo.fi wrote:
| I have been working on connections between R and my computational
| platform on Linux. I have designed a bridge function in C++ using
| RInside and the connection seems to work as expected now. However, I
| have a question regarding the heap memory usage.
| First, take a look at the Valgrind report for a short run without any
| R-connections in the executable:
| ==13263== Memcheck, a memory error detector
| ==13263== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
| ==13263== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
| ==13263== Command: ./supergha stoxx
| ==13263== Parent PID: 1
| ==13263== HEAP SUMMARY:
| ==13263== in use at exit: 0 bytes in 0 blocks
| ==13263== total heap usage: 81,741 allocs, 81,741 frees, 45,942,809
| bytes allocated
| ==13263== All heap blocks were freed -- no leaks are possible
| ==13263== For counts of detected and suppressed errors, rerun with: -v
| ==13263== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
You have to show us the code for the 'null model' here.
| Next, take a look at the Valgrind report with exactly the same run, but
| with <RInside.h> included in a h-file. Furthermore, I define a C++ class
I am afraid that this is not a valid baseline. As I attempted to explain
previously, embedding R entails embedding an entire interpreter with its
own memory management and memory pool.
A proper baseline comparison might start by following "Writing R Extensions"
and to see how to embed R 'by hand' in C/C++ executable. _That_ version
could then be compared to RInside to assert whether or not RInside has
| for the communication between C++ and R in the same h-file. However,
| this class is never used in the program. The only thing connecting the
| program to R is the preprocessor directive #include <RInside.h>. No
| R-computations at all. No new allocations in the code. No embedded R-calls:
| ==13875== Memcheck, a memory error detector
| ==13875== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
| ==13875== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
| ==13875== Command: ./supergha stoxx
| ==13875== Parent PID: 1
| ==13875== HEAP SUMMARY:
| ==13875== in use at exit: 8 bytes in 1 blocks
| ==13875== total heap usage: 81,767 allocs, 81,766 frees, 45,986,922
| bytes allocated
| ==13875== 8 bytes in 1 blocks are still reachable in loss record 1 of 1
| ==13875== at 0x4A06A2E: malloc (vg_replace_malloc.c:270)
| ==13875== by 0x33B08042B8: ??? (in /usr/lib64/libgomp.so.1.0.0)
| ==13875== by 0x33B080ED1A: ??? (in /usr/lib64/libgomp.so.1.0.0)
| ==13875== by 0x33B0805452: ??? (in /usr/lib64/libgomp.so.1.0.0)
| ==13875== by 0x33B0810A25: ??? (in /usr/lib64/libgomp.so.1.0.0)
| ==13875== by 0x33B0803E62: ??? (in /usr/lib64/libgomp.so.1.0.0)
| ==13875== by 0x7FF000449: ???
| ==13875== by 0x78786F7473006167: ???
| ==13875== by 0x6F723D52455354FF: ???
| ==13875== by 0x4C00616D72657472: ???
| ==13875== by 0x723D454D414E474E: ???
| ==13875== by 0x616D726574736E: ???
| ==13875== LEAK SUMMARY:
| ==13875== definitely lost: 0 bytes in 0 blocks
| ==13875== indirectly lost: 0 bytes in 0 blocks
| ==13875== possibly lost: 0 bytes in 0 blocks
| ==13875== still reachable: 8 bytes in 1 blocks
| ==13875== suppressed: 0 bytes in 0 blocks
| ==13875== For counts of detected and suppressed errors, rerun with: -v
| ==13875== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
| Since my platform scales with tens of thousands of parallel processors
| as I have demonstrated in numerous papers, I want to be sure that no
| heap memory faults are included in the program for example through R
| before invoking it in production runs.
| Ralf Östermark
| Ph.D(econ), Ph.D(pol)
| Professor of Accounting and Optimization Systems
| School of Business Economics at
| Åbo Akademi University
| 20500 Åbo
| Rcpp-devel mailing list
| Rcpp-devel at lists.r-forge.r-project.org
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
More information about the Rcpp-devel