Jump to content
  • Advertisement
Sign in to follow this  
kayX

Potential managed dx memory leak?

This topic is 4859 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am making an application using Managed directX and when i run it, my memory usage viewed under Windows Task Manager (Processes) keeps on going higher. I trace it to this line of code new VertexDeclaration(device, meshVertexElement); To confirm this, i make a test project with basic initialization codes and put this line of code into a function and call it in my main loop. The same thing happens. Since this object will go out of scope at the end of the function, it should be destroyed and the memory should some how be release. I even tried inserting GC.Collect() at the end of the function and it still behave the same. Does anyone encounter this problem and have a solution? Dx bug? or maybe i made a mistake? Pls shed some light

Share this post


Link to post
Share on other sites
Advertisement
Are you calling Dispose on the object? A lot of the classes in MDX follow the "Dispose Pattern", which basically means that when you are done with them you need to call the Dispose function of the class. This cleans up the unmanaged resources behind DirectX. If you just let it go out of scope the GC is only picking up after the managed parts of the classes and missing the rest of them.

Share this post


Link to post
Share on other sites
Thanks for the fast reply. Anyway, i did call dispose() but it only works for the simple project that i make to test. On my application, it doesnt seems to work although the allocation per update is lessen. I suspect that it might be other parts of the code where i fail to call dispose() but when i remove the lines


device.VertexDeclaration.Dispose();
device.VertexDeclaration = null; //to be save
device.VertexDeclaration = VertexDeclaration(device, meshVertexElement);

the allocation stops. which means that this 3 lines of code is the problem. Or maybe i over looked some part of my codes

Share this post


Link to post
Share on other sites
Quote:
Original post by kayX
Thanks for the fast reply. Anyway, i did call dispose() but it only works for the simple project that i make to test. On my application, it doesnt seems to work although the allocation per update is lessen. I suspect that it might be other parts of the code where i fail to call dispose() but when i remove the lines


device.VertexDeclaration.Dispose();
device.VertexDeclaration = null; //to be save
device.VertexDeclaration = VertexDeclaration(device, meshVertexElement);

the allocation stops. which means that this 3 lines of code is the problem. Or maybe i over looked some part of my codes

Is that the exact code? I'm just wondering if there is actually a new in front of the VertexDelceration constructor call, which is what I am assuming that is.

Are you making sure to call Dispose on the new objects too? Also, Task Manager isn't really a valid way of watching memory consumption in this case, it could just be that the Garbage Collector hasn't decided to collect yet. For some more .Net based memory watching, go to the Performance item in your Control Panel. You will need to click the plus sign and add the .Net statisitcs you are itnerested in, like how many Gen0/1/2 collections are going on.

Share this post


Link to post
Share on other sites
Sorry there is new in the front. Ok.. i try to look at the memory part more. Thanks for the feedback

Share this post


Link to post
Share on other sites
When the GC decides to do a collection, you won't see any memory reduction in the task manager. The GC works on the managed heap, which is a pre-allocated chunk of memory. So when it does a collection, all it does is re-arrange stuff in this managed heap (memory chunk), but won't necessarily shrink it or anything.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!