My R ma wycieki pamięci?

Question

Używam R 2.15.3 na Ubuntu 12.04 (precyzyjne) 64-bit. Jeśli biegnę R w valgrind:

R -d "valgrind" --vanilla

I wtedy wyjść z programu za pomocą q() i pojawia się następujący raport:

==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) 

Ostatnio R często się zawiesza, szczególnie gdy wywołuję funkcje C++ przez Rcpp, czy to może być powód? Dzięki!

Answer 1

Być może błędnie odczytujesz wynik valgrind. Najprawdopodobniej nie ma tu (oczywistego) wycieku, ponieważ R jest dość dobrze przebadany jako system. A jednak R jest językiem o dynamicznym typie, który oczywiście dokonał przydziałów. "Zdecydowanie zagubiony: 120 bajtów" jest w zasadzie błędem pomiaru - patrz dokumentacja valgrind.

Jeśli chcesz zobaczyć przeciek, utwórz je, na przykład, z pliku jak poniżej:

library(Rcpp) 
cppFunction('int leak(int N) {double *ptr = (double*) malloc(N*sizeof(double)); \ 
      return 0;}') 
leak(10000) 

który zastrzega pamięć, nawet wyraźnie poza zasięgiem R, a następnie kończy działanie. Tutaj otrzymujemy:

$ 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) 
$ 

Teraz jest nieco więcej wycieku (choć nadal nie jest tak łatwo czytelny, jak można by mieć nadzieję). Jeśli dodasz sugerowane flagi, w końcu wskażesz na wykonane przez nas połączenie malloc().

Mam również udokumentowany przykład rzeczywistego wycieku we wcześniejszej wersji pakietu CRAN w jednym z zestawów slajdów "Wprowadzenie do HPC z R". Jeśli i kiedy wystąpi wyciek, pomaga to. Kiedy go nie ma, trudniej jest go przejrzeć.

Krótko mówiąc, jeśli kodują awarie, prawdopodobnie jest to wina twojego kodu. Spróbuj minimalnego odtwarzalnego przykładu to (dobra) standardowa rada.