My R has memory leaks?

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.