My R ha perdite di memoria?

Question

Sto usando R 2.15.3 su Ubuntu 12.04 (preciso) a 64 bit. Se corro R in valgrind:

R -d "valgrind" --vanilla

ho quindi uscire dal programma utilizzando q() e ottengo il seguente rapporto:

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

Ultimamente R si blocca abbastanza spesso, specialmente quando chiamo le funzioni C++ tramite Rcpp, potrebbe essere questo il motivo? Grazie!

Answer 1

È possibile che l'uscita valgrind sia stata letta erroneamente. Molto probabilmente, qui non vi è alcuna perdita (ovvia) poiché R è piuttosto ben studiato come sistema. Tuttavia R è un linguaggio tipizzato dinamicamente che ha ovviamente fatto assegnazioni. "Definitely lost: 120 bytes" è essenzialmente un errore di misura - vedi i documenti valgrind.

Se volete vedere una perdita, crearne uno, per esempio, con un file in questo modo:

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

che si riserva di memoria, anche esplicitamente fuori dalla portata di R, e poi esce. Qui abbiamo:

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

Ora c'è un po 'più di una perdita (anche se non è ancora facilmente leggibile come si potrebbe sperare). Se aggiungi i flag suggeriti, alla fine indicherà la chiamata malloc() effettuata.

Inoltre, ho un esempio funzionante di perdita effettiva in una versione precedente di un pacchetto CRAN in uno dei miei set di slide "Introduzione a HPC con R". Se e quando c'è una perdita, questo aiuta. Quando non ce n'è, è più difficile vedere attraverso il rumore.

Quindi, in breve, se si interrompe il codice, è probabilmente colpa del codice. Prova un esempio riproducibile minimo è il (buon) consiglio standard.