Cross thread memory leak detection
Author
In my program I've allocated (new) an object in one thread, which I then deallocate (delete) on exiting the program in a different thread. The problem is, Visual C's built-in detector shows a memory leak.
I'm fairly certain the object is being deleted properly (I put breakpoints in the destructor where delete is called to check). Is this theory correct, and Visual C's memory leak detector simply can't handle cross-thread allocation/deallocation? If so, is there any way around it?
Cheers,
Make sure you're not allocating it twice, and deleting it once. Breakpoint the allocation as well as the delete.
Author
Thanks for the suggestion. Just tried that, and indeed it is only being allocated/deallocated once.
Are you saying that VC's built-in memory leak detector is working in this case, and there is definately something else going on?
Are you saying that VC's built-in memory leak detector is working in this case, and there is definately something else going on?
If it was unable to handle cross-thread allocation/deallocation it would be rendered completely unusable for... well, anything. So I suspect something else is going on.
Author
Aha! Thanks ladies. Prompted by your replies, I looked deeper into the memory leak and found that the library I am using (specifically OgreBulletDynamics::VehicleTuning) has a bug (I suspect it is, anyway), wherein it fails to delete an internally created object in its destructor.
Phew! Nearly an entire day's work to get this result. Gotta love programming.
Phew! Nearly an entire day's work to get this result. Gotta love programming.
Quote:Original post by dangerdaveCS
Nearly an entire day's work to get this result. Gotta love programming.
Something to think about:
Assuming 35 years, 270 workdays/per year, that means at such rate, one would only be able to solve 9500 bugs of this type in entire career, doing nothing else at all. A typical project with dozens of developers has less bug reports during life time (Firefox example).
Now consider that memory leak from a temporary simply cannot exist in any managed language.
Just a little perspective on complexity and cost of development as well as productivity.
A note on threads - before relying on leak checkers, make sure to correctly stop each and every thread, and let each of the parts handled by them shut down completely, before finally exiting the application.
While ExitProcess is preferred for various reasons, it will also make leak detectors useless.
Quote:Original post by AntheusQuote:Original post by dangerdaveCS
Nearly an entire day's work to get this result. Gotta love programming.
Something to think about:
Assuming 35 years, 270 workdays/per year, that means at such rate, one would only be able to solve 9500 bugs of this type in entire career, doing nothing else at all. A typical project with dozens of developers has less bug reports during life time (Firefox example).
Now consider that memory leak from a temporary simply cannot exist in any managed language.
The bug was not in his own code. If you think there's never any bugs or leaks in Java or C# you just haven't used them enough.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
