The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
Is there a finalizer in the HDElement class and that is the Dispose pattern is properly implemented. If yes then where are you experiencing memory leaks? and why is that such a major issue are the users experiencing some issues? Now it may be that GC may not be reclaiming HDElement at a time when you expect if the bulk of the memory used by HDElement is in the unmanaged resources. If you can modify the source code of HDElement, I think you should consider AddMemoryPressure method.
Vikram, there's a "using" statement in C# that does the try...finally thing in a nice syntax that guarantees that Dispose() gets called. I'd have a link to the MSDN, but my access to MSDN seems to be oddly broken at the moment.
You do need to implement IDisposable and ensure that the Dispose method actually does something! I think there may be a couple of articles here that give a good overview (you can find them). If not I can send you some code if you like.
Thanks for the reply, Gary, but I wasn't looking for coding tips to handle the memory leak. I know perfectly well what needs to be done, I was wondering if there is a tool that can do this for me or I had to review the entire code.
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
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 ) and replacing all HDElement instances with my subclass.
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
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).
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.
I've been looking for a simple way to manage my DVD video encoding jobs and possibly distribute them across my multiple computers. It seems that grid computing could provide an answer, but so far my attempts haven't met much success (I've tried Alchemi and Fura).
It seems that these systems are overly complicated and not well suited for general, simple job management. So my question is: Is there much need for this? Do you guys have several computers you wish could be used for movie or other (say programming) jobs? Any suggestions on where to start for the job management (command line tasks) across computers?
I've been looking for a simple way to manage my DVD video encoding jobs and possibly distribute them across my multiple computers.
Unlikely that this will help a single job unless whatever processing software can effectively make use of many cores. I have seen a lot of software not make use of 4 cores for this type of operation. I would just spend $900 US (about $300 for the cpu $300 for memory and $300 for a good motherboard) instead. With an i7 you will have 4 real cores and 4 HT cores. I really doubt whatever software you are using will use more than that on a single video operation. A different idea is to do independent encodings on each system.
Provided whatever job you are running can be executed from the command line, it is simple and straightforward - XGE automatically virtualises all file and registry accesses, so quite literally all you need to do is throw a configuration file at it and wait for the results to come in.