I'm trying to hunt down a very evasive bug in a server software that look like a memory leak, but memcheck didn't help at all. My guess is that the memory that has been instantiated and never removed is indeed not leaked, so there is a reference to it, but is now useless for the program and should be removed. Is there a tool that can count accesses, not references, in memory, and so give a evaluation of the effective usage of objects in heap?
Asked
Active
Viewed 601 times
7
-
1Valgrind should report stuff that's never been freed as "still reachable"; see http://valgrind.org/docs/manual/faq.html#faq.deflost. – Oliver Charlesworth Dec 26 '11 at 17:40
-
@oli - you might want to post your comment as an answer so that it can be marked as accepted. It looks like the right answer to me, anyway. – casualcoder Dec 27 '11 at 15:27
-
I've already run memcheck with this program and it didn't show anything. – Lorenzo Pistone Dec 28 '11 at 09:40
2 Answers
4
I ended up with implementing my own tool. My approach was slightly different from what I intended: I wrote a malloc hooking library. It hooks malloc, realloc and free, and maintains a list of living malloc'd memory blocks. Whenever you send a SIGUSR1 to your application, it dumps its info in a file, and evaluate it as a Mathematica expression. The Mathematica notebook finally provide some very useful graphs: top scored instantiations by call stack, and a complete overview of calls to malloc. With these tools, I just had to hover my mouse on the fattest and most distant from the center green dot of the second graph, and, voilà, I have the address that instantiates loads of not leaked but useless memory.
P.S. The circular calls that you can see in the second graph are definitely a bug in libc's backtrace().
Lorenzo Pistone
- 5,028
- 3
- 34
- 65
-
I'm surprised valgrind didn't do what you wanted it to, there hasn't been a memory leak valgrind hasn't picked up for me. – dreamlax Dec 28 '11 at 09:47
-
This bug is extremely elusive for another reason: another guy has found a way to reliably trigger it on his build, but that method doesn't work for mine (same fresh untouched source, of course). So memcheck didn't find anything obviously for me, but this guy told me that he did run memcheck and it returned nothing, and I have no reason to think that he did something wrong. The data shown in the graphs come from his build too. I suspect that it's somehow related to bitness, he builds 32 bit executable to be able to share the same build on any server, whereas I built only 64 bits executables. – Lorenzo Pistone Dec 28 '11 at 10:01
0
Probably this tool (Visual Leak Detector) will help you. It's free.
nickolay
- 3,643
- 3
- 32
- 40
-
it looks like a normal leak detector, as I said my problem is that the extra memory in use is not technically leaked, because there are still references to it. Also, I'm working with gcc. – Lorenzo Pistone Dec 27 '11 at 09:53