Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Checking Ruby C Extensions for memory leaks. #7

Open
abinashmeher999 opened this issue Jan 25, 2016 · 0 comments
Open

Checking Ruby C Extensions for memory leaks. #7

abinashmeher999 opened this issue Jan 25, 2016 · 0 comments
Labels

Comments

@abinashmeher999
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant