My R has memory leaks? - r

Question

I'm using R 2.15.3 on Ubuntu 12.04 (precise) 64-bit.
If I run R in valgrind:
R -d "valgrind" --vanilla
I then exit the program using q() and I get the following report:
==7167== HEAP SUMMARY:
==7167== in use at exit: 28,239,464 bytes in 12,512 blocks
==7167== total heap usage: 28,780 allocs, 16,268 frees, 46,316,337 bytes allocated
==7167==
==7167== LEAK SUMMARY:
==7167== definitely lost: 120 bytes in 2 blocks
==7167== indirectly lost: 480 bytes in 20 blocks
==7167== possibly lost: 0 bytes in 0 blocks
==7167== still reachable: 28,238,864 bytes in 12,490 blocks
==7167== suppressed: 0 bytes in 0 blocks
==7167== Rerun with --leak-check=full to see details of leaked memory
==7167==
==7167== For counts of detected and suppressed errors, rerun with: -v
==7167== Use --track-origins=yes to see where uninitialised values come from
==7167== ERROR SUMMARY: 385 errors from 5 contexts (suppressed: 2 from 2)
Lately R is crashing quite often, especially when I call C++ functions through Rcpp,
could this be the reason?
Thanks!

Answer 1

You may be misreading the valgrind output. Most likely, there is no (obvious) leak here as R is pretty well studied as a system. Yet R is a dynamically typed language which has of course done allocations. "Definitely lost: 120 bytes" is essentially measurement error -- see the valgrind docs.
If you want to see a leak, create one, e.g., with a file like this:
library(Rcpp)
cppFunction('int leak(int N) {double *ptr = (double*) malloc(N*sizeof(double)); \
return 0;}')
leak(10000)
which reserves memory, even explicitly out of R's reach, and then exits. Here we get:
$ R -d "valgrind" -f /tmp/leak.R
[...]
R> leak(10000)
[1] 0
R>
==4479==
==4479== HEAP SUMMARY:
==4479== in use at exit: 35,612,126 bytes in 15,998 blocks
==4479== total heap usage: 47,607 allocs, 31,609 frees, 176,941,927 bytes allocated
==4479==
==4479== LEAK SUMMARY:
==4479== definitely lost: 120 bytes in 2 blocks
==4479== indirectly lost: 480 bytes in 20 blocks
==4479== possibly lost: 0 bytes in 0 blocks
==4479== still reachable: 35,611,526 bytes in 15,976 blocks
==4479== suppressed: 0 bytes in 0 blocks
==4479== Rerun with --leak-check=full to see details of leaked memory
==4479==
==4479== For counts of detected and suppressed errors, rerun with: -v
==4479== Use --track-origins=yes to see where uninitialised values come from
==4479== ERROR SUMMARY: 31 errors from 10 contexts (suppressed: 2 from 2)
$
Now there is a bit more of a leak (though it is still not as easily readable as one would hope). If you add the suggested flags, it will eventually point to the malloc() call we made.
Also, I have a worked example of actual leak in an earlier version of a CRAN package in one of my 'Intro to HPC with R' slide sets. If and when there is a leak, this helps. When there is none, it is harder to see through the noise.
So in short, if you code crashes, it is probably your code's fault. Try a minimal reproducible example is the (good) standard advice.