Automated way of checking if all instances of a type have been properly disposed of [modified]

[Vikram A Punathambekar]

Thanks for the tip, and thanks for not flaming :) HDElement holds unmanaged resources, so the GC won't do. Modifying its source is out of question, so I will have to review all of my app's code and call Dispose manually.

Cheers, Vıkram.

---

I don't suffer from insanity, I enjoy every moment of it.

[Vikram A Punathambekar]

Thanks for the comment, Rob, but I didn't know asking for automated tools qualified as a programming question. Still, I have created a separate apology thread.

Cheers, Vıkram.

---

I don't suffer from insanity, I enjoy every moment of it.

[S Senthil Kumar]

I ran into a similar problem a while back, but we owned the code for the type (you could always disassemble/assemble). My solution was to store the stack trace of the constructor of every instance of that type as a member in that type, and then in the finalizer, log the stack trace. I also ran a timer in the background that periodically called GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect();. That way, the finalizer would run for all instances that did not get disposed, and I would be able to see where those instances got created. I would then run the application and try to exercise all paths in the code that deal with that type. I would then go through the log and fix code that was not disposing instances. The trick is to make sure that all code paths that involve that type are exercised, and that's what makes this non-deterministic. A tool like NCover would probably help track code coverage. You just gave me an idea - it would be nice to have a tool automate the first part (track instances and report where they are created in code). Now I know what I'll be doing over the Republic Day weekend :) Hope this helps.

Regards Senthil [MVP - Visual C#] _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro

[Vikram A Punathambekar]

Thanks for your reply, Senthil. Making any changes to the type itself is out of question. I ploughed through the code today, adding Dispose() calls, and will see tomorrow if it has had any effect. If not, I'll go with your idea of logging the stack trace by inheriting the class (I hope they didn't seal it :doh: ) and replacing all HDElement instances with my subclass. Send me the link when your article is ready ;)

Cheers, Vıkram.

---

I don't suffer from insanity, I enjoy every moment of it.

[PIEBALDconsult]

Now there's a straight line: "... only their darn stupid questions." "... monkeys on the other hand..." :-D

[Adar Wesley]

To find memory leaks in a program C# or C++ at runtime use Purify Or DevPartner For static code analysis, I am sure it is possible to create an appropriate FxCop rule. --- Adar Wesley

[S Senthil Kumar]

If you are still working on fixing the leak, I have a basic version of my app here[^]. It uses the CLR Profiling API to track object allocations and finalizations and shows the constructor stack trace for finalized objects. Just give it the list of fully qualified names (including namespace) of the types you want to monitor and run the application - It will log all data to a file you specify. It has a couple of kinks - you'll have to give some type name i.e. you can't monitor all types, inner classes don't work if the class name is fully qualified, and the stack trace doesn't include method parameter/return types. Worth a try if you are still struggling with the leak :)

Regards Senthil [MVP - Visual C#] _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro

[Vikram A Punathambekar]

Senthil, this is much appreciated. I later realized the numbers I was seeing in task manager were not accurate, and found some articles that demonstrated this (the bookmarks are at work). I have come around to the conclusion that there is probably no leak, but all that work did not go waste: I was able to bring down the memory usage by more than 25% by rewriting the code to use Dispose() and making a few calls to GC.Collect(). I've downloaded and mailed your app to my office ID so I can play with it on Monday (I don't do any dev work at home). Again, many thanks! :)

Cheers, Vıkram.

---

I've never ever worked anywhere where there has not been someone who given the choice I would not work with again. It's a job, you do your work, put up with the people you don't like, accept there are probably people there that don't like you a lot, and look forward to the weekends.   - Josh Gray.

[Nish Nishant]

Vikram A Punathambekar wrote:

Send me the link when your article is ready

Perhaps he's already done this, but in case he hasn't : Finding undisposed objects[^]

Regards, Nish

---

Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
My latest book : C++/CLI in Action / Amazon.com link

[Vikram A Punathambekar]

Thanks! I wanted to ask how you stumbled across this now, but I see he's included a link. :)

Cheers, Vikram. (Proud to have finally cracked a CCC!)

Recent activities: TV series: Friends, season 10 Books: Fooled by Randomness, by Nassim Nicholas Taleb.

---

Carpe Diem.