Description
Moved from symengine/symengine#501
If you’re using a C extension that’s leaking memory there are tools specific to the C language that can help you find memory leaks (Valgrind). If you have Ruby code that is leaking memory there are tools specific to the Ruby language that can help you (memprof).[1]
I have come across many tools for checking for memory leaks in Ruby, but for testing the C extensions, Valgrind and gdb are the ones that almost all of the blogs suggest.
Checking for memory leaks can be done at two levels.
- One after the functions have been wrapped in Ruby, from their rspec test files.
- The other with the testcases written using the functions written using Ruby C API. We don't have these kind of tests yet.
If we check for memory leaks only with the latter cases, there wouldn't be much to check for in the rspec test files and we can be fairly sure that memory leaks won't be happening thereafter. This would be partly because any leaks arising solely out of Ruby code would be mostly dependent on the user of the Ruby interface and not because of any issue in the c functions, or any cause of leak in the extensions. So, testcases written using Ruby C API should filter most of the memory leaks.
Yet, I have found example where they have tested them on the ruby test(nokogiri). And one where they checked in C tests(cranberry).
rake-tester
rake-tester is an extension to the rake-compiler, which also offers gdb and valgrind integration.
Running a test in gdb or valgrind will be as easy as
rake test:gdb:symengine[test]
rake test:valgrind:symengine[test]That's why I would also like to ask if bringing back rake is possible. The "The Workflow" section here especially, is tempting.
Checking of memory leaks with Travis
Since it is difficult to tell what are unintentional memory leaks, it will be very difficult to say if we have memory leaks just by a script. Any ideas for integrating this with travis are welcome.