[Rcpp-devel] Incomplete Heap memory freeing under R

[rosterma at abo.fi]

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==
==13263==
==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==
==13263== All heap blocks were freed -- no leaks are possible
==13263==
==13263== For counts of detected and suppressed errors, rerun with: -v
==13263== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)

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 
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==
==13875==
==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==
==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==
==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==
==13875== For counts of detected and suppressed errors, rerun with: -v
==13875== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
/home/aton6/rosterma/research/catsm/super_catsm_R/stoxx_50/valgrind_test>

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
Finland