[Rcpp-devel] Does uncaught c++ exception cause memory leak?

[Qiang Kou]

Hi, Wush,

It seems that memory leakage has nothing to do with R.

Just use your code without R:

#include <iostream>
#include <stdexcept>

int main(int argc, char **argv) {

    std::string msg = std::string("test");
    throw std::logic_error(msg);
    return 0;
}

I still get the same leakage information:

==19532== Memcheck, a memory error detector
==19532== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==19532== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright
info
==19532== Command: ./a.out
==19532==
terminate called after throwing an instance of 'std::logic_error'
  what():  test
==19532==
==19532== HEAP SUMMARY:
==19532==     in use at exit: 173 bytes in 2 blocks
==19532==   total heap usage: 3 allocs, 1 frees, 205 bytes allocated
==19532==
==19532== LEAK SUMMARY:
==19532==    definitely lost: 0 bytes in 0 blocks
==19532==    indirectly lost: 0 bytes in 0 blocks
==19532==      possibly lost: 173 bytes in 2 blocks
==19532==    still reachable: 0 bytes in 0 blocks
==19532==         suppressed: 0 bytes in 0 blocks
==19532== Rerun with --leak-check=full to see details of leaked memory
==19532==
==19532== For counts of detected and suppressed errors, rerun with: -v
==19532== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
*Aborted (core dumped)*

The program may abort before releasing the resource, so there may be memory
leak.

With try/catch, the program will exit normally. So no leakage found.

Best,

KK


On Mon, Dec 29, 2014 at 10:05 PM, Dirk Eddelbuettel <edd at debian.org> wrote:

>
> PS  Here is a better variant that actually leaks:
>
> edd at max:/tmp$ cat leak.cpp
>
> #include <cstdio>
> #include <cstdlib>
> #include <iostream>
> #include <cmath>
>
> int main() {
>   double *d = new double[1024];
>   if (d) std::cout << "Allocated" << std::endl;
>   double e = std::exp(1.0);
>   d = &e;
>   exit(0);
> }
> edd at max:/tmp$ g++ -Wall -o leak leak.cpp
> edd at max:/tmp$ valgrind  ./leak
> ==16924== Memcheck, a memory error detector
> ==16924== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==16924== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright
> info
> ==16924== Command: ./leak
> ==16924==
> Allocated
> ==16924==
> ==16924== HEAP SUMMARY:
> ==16924==     in use at exit: 8,192 bytes in 1 blocks
> ==16924==   total heap usage: 1 allocs, 0 frees, 8,192 bytes allocated
> ==16924==
> ==16924== LEAK SUMMARY:
> ==16924==    definitely lost: 8,192 bytes in 1 blocks
> ==16924==    indirectly lost: 0 bytes in 0 blocks
> ==16924==      possibly lost: 0 bytes in 0 blocks
> ==16924==    still reachable: 0 bytes in 0 blocks
> ==16924==         suppressed: 0 bytes in 0 blocks
> ==16924== Rerun with --leak-check=full to see details of leaked memory
> ==16924==
> ==16924== For counts of detected and suppressed errors, rerun with: -v
> ==16924== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> edd at max:/tmp$
>
> By overwriting d the memory is lost for good, and valgrind notices as you;d
> think it would.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>



-- 
Qiang Kou
qkou at umail.iu.edu
School of Informatics and Computing, Indiana University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20141229/fa146c51/attachment-0001.html>