I was wondering if anyone was doing work on this. If not, maybe I can find the time to do so. What I am looking for is real time leak checking. When a leak occurs, it could be immediately reported with a trace of where it was allocated and where it was leaked. Off the cuff, I can think of 3 types of leaks that can occur: 1) Leaks due to assignment. mem = malloc(..) mem = other_pointer (mem leaked) 2) Leaks due to loss of scope. func(..) { char * p = malloc(..) } (p out of scope, leaked) 3) Leaks due to freeing containing stuctures. struct x {char * p; }; x = malloc(sizeof(struct x)); x->p = malloc(...); free(x); (p leaked) With the last one being the most difficult (performance wise) to detect. Is there anything prohibiting something like this from being implemented without an extremely serious performance hit? Seems like an indexed table of reference counts and checks on pointers being copied/assigned is all thats needed. This is all off the top of my head, so I am sure I am missing some obvious issues. Let me know what you think. Joe
On Wed, 11 Feb 2004, Joseph Link wrote: > Is there anything prohibiting something like this from being implemented > without an extremely serious performance hit? Seems like an indexed table of > reference counts and checks on pointers being copied/assigned is all thats > needed. I think that table and those checks would give exactly that performance hit, every assignment would have to be monitored for pointer creation/destruction, ie. the usual reference counting problem. That's assuming you can track your pointers accurately, which is not straightforward. A deeper question is this: why do you want real-time leak checking? Do you have a long-running app, and you don't want to wait until it completes to get the leak report? In which case careful insertion of the VALGRIND_DO_LEAK_CHECK() client request into your code could be useful. Another nice feature that would achieve something similar would be if there was an interactive way to trigger a client request while running, eg. by sending a signal or doing some obscure key combination.
The real issue I am trying to solve with this request is actually being able to fix the leak. As it is now, you only know what piece of memory was leaked and where it was originally allocated. I am not sure if my situation is the norm, but I use a lot of asynchronous programming and it is very difficult to track where the leak could have possibly occurred. With the real time checking, you could report the exact location that the leak occurred (in addition to where it was allocated). This is ideal (and something that insure++ has spoiled me with). Perhaps, runtime leak testing wouldn't be too terrible a performance hit if it was the only type of checking being run. ie, First run with no leak checking to ensure there are no errors, and then run with only leak checking. Joe Nicholas Nethercote wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=74899 > > > > > ------- Additional Comments From njn25@cam.ac.uk 2004-02-11 01:19 ------- > On Wed, 11 Feb 2004, Joseph Link wrote: > > >>Is there anything prohibiting something like this from being implemented >>without an extremely serious performance hit? Seems like an indexed table of >>reference counts and checks on pointers being copied/assigned is all thats >>needed. > > > I think that table and those checks would give exactly that performance > hit, every assignment would have to be monitored for pointer > creation/destruction, ie. the usual reference counting problem. That's > assuming you can track your pointers accurately, which is not > straightforward. > > A deeper question is this: why do you want real-time leak checking? Do > you have a long-running app, and you don't want to wait until it completes > to get the leak report? In which case careful insertion of the > VALGRIND_DO_LEAK_CHECK() client request into your code could be useful. > > Another nice feature that would achieve something similar would be if > there was an interactive way to trigger a client request while running, > eg. by sending a signal or doing some obscure key combination.
Ah, ok. Do you know how Insure++ does this? Does it really do reference counts and update them at every step? Is it in the "normal" mode or the more thorough "recompile" mode?
> Ah, ok. > > Do you know how Insure++ does this? Does it really do reference counts > and update them at every step? Is it in the "normal" mode or the > more thorough "recompile" mode? I've never used insure in normal mode. I have only compiled my apps with it when doing leak checking. Obviously, with recompile mode, you can be really smart about it.
It looks like the app _needs_ to be compiled to enable the real time leak detection. If you just run the app with insure, it behaves like valgrind and gives you a report of all the leaked blocks at the end of the app.
*** Bug 371770 has been marked as a duplicate of this bug. ***