Dispose MonoGame not working (Keyboard.GetState() and increased memory)

Windows
1

I been searching the web for a solution and found several people struggling with memoryleak using MonoGame while trying to dispose objects. It could be the case that MonoGame should be started and closed as a own process, not from inside of another program which are my case. This is my application. When I click on the button, a new thread is created and the MonoGame application is started:

 viThread = new Thread(startDemo);
 viThread.Priority = ThreadPriority.Highest;
 viThread.Start();

 private void startDemo()
 {
        using (Demo d = new Demo())
            d.Run();
 }

The “Demo” is closed by a Game.Exit() command and i have also tried with Disposed(true) without any success. Next time I launch the MonoGame is Keyboard.GetState() always empty and the memory is incresed. I made a loop where I started and closed the application 100times and it are eating my memory. I have seen lots of discussion about SharpDX not working correcly with disposing resources. So here I am, stuck. Just want to point out that this worked fine for XNA but not now when changed to MonoGame.

I uploaded a .sln project as example where you can see for yourself the issue. I been looking 2-3 days without solution, thinking about move on to Unity if that could be a way to handle this.
Download sln project - example

2

So your Demo class inherits from MonoGame/Xna Game class?

I wonder if there is a real need to recreate the whole MonoGame instance each time? Perhaps you could make your own class MyGame which is hosted inside a Game instance. It could be recreated each time have content.Unload() called. That’s kind of what I do for my editor.

That said, you might be able to use a memory profiler to find out why the memory is leaking. Also debugging might discover why Keyboard.GetState stops working, but my guess on both is that it’s to do with static variables not being unset.

3

The problem is related to threading. Since the game is started in a new thread, and when exit is the thread close. However, the application is increasing in resources (memory), so there must be another “background-thread” that is keeped alive somehow?

4

Well whichever thread is calling startDemo() will still be alive after the demo game exits. Also static variables will still be alive after a thread ends, and these statics may reference resources which cause your memory leak. Also any undisposed native resources will still be retained. Are you definitely calling content.Unload()?

Since Game.Run() is tied to the windows message loop, I’d advise against attempting do do this more than once during a single program’s execution. It may be possible, but it was never meant to be used this way. In fact, even the Xna WinForms sample does not use the Game class because of this reason.

5

Thanks for the feedback!
Love that you can come back on a monday morning and learn new stuff directly!
The thread which call startDemo() is closed when the game end. I have verified that in VS2013 by looking on which threads that are running from the application.
I have done Content.Unload(), but dosn’t make any difference. In my eyes its the same as when the thread closes (if the GC know what to do).
Yeah I got that feeling as well. Normaly you just create a game with the “menu” inside the MonoGame/XNA but we are using it as an animiation to show an example. However, it worked just fine with the latest version of XNA since we could call for this.Dispose() before the line this.Exit(), but since we updated to MonoGame that’s no longer possible, it will crash.

I got some nice feedback here where they have verified the issue and are looking into it: