allocated by CLR initialization?
cider123
Posts: 3
I have a desktop app that starts out normal, but ever so slowly eats away at memory without the User doing anything in the app.
It's a system tray type of an application, and I use threadpooling to launch off tasks. Best I can manage, I clean up everything that is possible, but the task manager and perfmon tell a different story.
When I installed the 3.2 profiler to check it out, I noticed a reference in the "Biggest live objects" when it starts out:
Object[] ID 6278 N/A 7,008 38,000
..and over time it grows, at which point after running for about 2 hours it now reads something like:
Object[] ID 6278 N/A 7,008 647,000
When I click on it to see where all the memory is getting allocated, it simply references in the status window at the bottom:
(Call Stack)
Object: Object[] ID 6278 allocated by CLR initialization
I went to the "All Classes" tab, grouped the Namespaces and then expanded my application namespace and noticed a few references to DataSet objects that are still "live" but when I click on each entry in the rows it doesn't give me any more details as to what or where those are being allocated.
I create Dataset objects in the class that is shelled by the ThreadPool manager, and then surface them through Events to the main GUI thread (which triggers an InvokeRequired). I close all references to the Dataset objects, in the class that is shelled and in the main GUI applications but for some reason the Live counts still remain.
Any feedback / direction greatly appreciated.
It's a system tray type of an application, and I use threadpooling to launch off tasks. Best I can manage, I clean up everything that is possible, but the task manager and perfmon tell a different story.
When I installed the 3.2 profiler to check it out, I noticed a reference in the "Biggest live objects" when it starts out:
Object[] ID 6278 N/A 7,008 38,000
..and over time it grows, at which point after running for about 2 hours it now reads something like:
Object[] ID 6278 N/A 7,008 647,000
When I click on it to see where all the memory is getting allocated, it simply references in the status window at the bottom:
(Call Stack)
Object: Object[] ID 6278 allocated by CLR initialization
I went to the "All Classes" tab, grouped the Namespaces and then expanded my application namespace and noticed a few references to DataSet objects that are still "live" but when I click on each entry in the rows it doesn't give me any more details as to what or where those are being allocated.
I create Dataset objects in the class that is shelled by the ThreadPool manager, and then surface them through Events to the main GUI thread (which triggers an InvokeRequired). I close all references to the Dataset objects, in the class that is shelled and in the main GUI applications but for some reason the Live counts still remain.
Any feedback / direction greatly appreciated.
Comments
Unfortunately I do not have an answer to this, but I can't leave it unanswered. I tried recreating your code by running a background thread that fires an event back to the main thread with a new DataSet object part of the EventArgs, and despite firing this ten times, I am left with 0 live DataSets.
As far as I know, objects allocated by CLR initialization are things like security and environment settings and maybe things allocated by type initialization (not sure, but would explain how you could influence this in your own code).
Next I created an internal variable of DataSet type, manually defined the table and columns for the DataSet and then used that to pass data through the system.
After that, all references to the DataSet objects disappeared from the profiler and the application no longer increased slowly in memory use.
I'm guessing all the code the DataSet template generates doesn't fully release even though I called Close and Dispose on the variable I used to create a new instance of it with.
When in doubt, go back to old school and manually code everything I guess. =D Was just trying to take advantage of some of the wizard driven template systems.