|
From: jlh <jl...@gm...> - 2008-05-16 22:49:08
|
Dirk Stöcker <valgrind <at> dstoecker.de> writes: > One of our software projects has same limitations. I added an interface, > which allows to store the input data and timestamps and also the reverse > (loading timestamps and data back from disk). Interesting, but in some situations this might require quite some changes to the application. The more I change the program, the more I'm at risk of not triggering the memory leaks I'm hunting for. I will try and see if I can do something in that direction. I suspect a certain part of the program to leak, I can probably do this after isolating that part. > Thought this method will probably only work, when the software design > allows a more or less central data input instead of lots of input floating > throught lots of different interfaces into the software. My software as a whole interacts with another program, so it's quite difficult to record the data and play it back later. But with that isolation it should work. > Also there are link library replacements for the malloc/free functions, > which allow the tracking you want to a certain degree (don't remember the > name, "electric fence"?) Thanks, I had a look at electric fence and it's not about memory leaks, but rather about buffer overruns. But there's a fork of efence called DUMA which intercepts calls to memory functions to trace down memory leaks. But it's mode of operation is to segfault whenever something bad is detected; it's meant to be run in a debugger, so you can immediately have a look at what happened. I prefer the way valgrind works: It collects all information but doesn't interrupt anything; then at the end you get a long report. Also, I somehow managed to overlook the most obvious candidate for finding memory leaks: mtrace. It's actually part of glibc and already was on my system. It still slows down the program quite a bit (DUMA did as well), but much less than valgrind, since only the memory function calls get slower, but the rest runs at native speed. It seem to be a great tool for C, but doesn't do well with C++. :( Thanks for all replies! I think I will have to go with isolating parts of the program that can run without the real-time pressure and run them with valgrind. Thanks, jlh |