My R has memory leaks? -
i'm using r 2.15.3 on ubuntu 12.04 (precise) 64-bit. if run r in valgrind:
r -d "valgrind" --vanilla
i exit program using q() , following report:
==7167== heap summary: ==7167== in use @ 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== 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 --leak-check=full see details of leaked memory ==7167== ==7167== counts of detected , suppressed errors, rerun with: -v ==7167== use --track-origins=yes see uninitialised values come ==7167== error summary: 385 errors 5 contexts (suppressed: 2 2) lately r crashing quite often, when call c++ functions through rcpp, reason? thanks!
you may misreading valgrind output. likely, there no (obvious) leak here r pretty studied system. yet r dynamically typed language has of course done allocations. "definitely lost: 120 bytes" measurement error -- see valgrind docs.
if want see leak, create one, e.g., file this:
library(rcpp) cppfunction('int leak(int n) {double *ptr = (double*) malloc(n*sizeof(double)); \ return 0;}') leak(10000) which reserves memory, explicitly out of r's reach, , exits. here get:
$ r -d "valgrind" -f /tmp/leak.r [...] r> leak(10000) [1] 0 r> ==4479== ==4479== heap summary: ==4479== in use @ 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== 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 --leak-check=full see details of leaked memory ==4479== ==4479== counts of detected , suppressed errors, rerun with: -v ==4479== use --track-origins=yes see uninitialised values come ==4479== error summary: 31 errors 10 contexts (suppressed: 2 2) $ now there bit more of leak (though still not readable 1 hope). if add suggested flags, point malloc() call made.
also, have worked example of actual leak in earlier version of cran package in 1 of 'intro hpc r' slide sets. if , when there leak, helps. when there none, harder see through noise.
so in short, if code crashes, code's fault. try minimal reproducible example (good) standard advice.
Comments
Post a Comment