It usually occurs after a few hours of renderingAh. So these functions work, but after a few hours the binding somehow gets unstable, right?
It looks like it should work fine ;DGreat. Then we're on the same page.
I'll try to test it; how do you check that it leaks? With the Windows task manager or with a dedicated tool?I use ANTS memory profiler, but leak is also obvious from task manager.
Glad I asked then :) This minimal example is leaking full on. What am I misunderstanding?
Thanks for your feedback.
The texture is correctly referenced in the sprite instance, and the sprite is used in the Draw call. In this scenario, I don't see how (when) the GC would collect one of these variables too early. When they are no longer referenced, they are not needed anymore.
And wouldn't that cause crashes rather than memory leaks?
Hi, I will be glad to give you the answer. I am the author of xInterop NGen++ at http://www.xInterop.com (http://www.xInterop.com), which is a C# wrapper generator for native C++ DLL. I recently wrapped SFML libraries for testing purpose. I had a similar issue with my version of SFML C# Wrapper generated by xInterop NGen++ at http://www.xinterop.com/index.php/2013/07/20/generating-sfml-c-net-wrapper-libraries-in-10-minutes-part-i/ (http://www.xinterop.com/index.php/2013/07/20/generating-sfml-c-net-wrapper-libraries-in-10-minutes-part-i/).
The cause of the issue is GC management. When you call into any C++ native DLL, you must make sure any C# instantiated object you pass to the native C++ method will not get GC-collected during the call.
The solution is to use GC.KeepAlive or using keyword(your choice) to make sure that. So, your code should like the following,var renderWindow = new RenderWindow(new SFML.Window.VideoMode(200, 200), "I'm a leaker");
while (true)
{
var texture = new Texture("nonprogressive.jpg");
var sprite = new Sprite(texture);
renderWindow.Draw(sprite);
renderWindow.Display();
renderWindow.DispatchEvents();
GC.KeepAlive(texture);
GC.KeepAlive(sprite);
GC.Collect();
}
GC.KeepAlive(renderWindow);
--------------------------------------------------------------------------------
Shawn Liu, Author of xInterop NGen++ at http://www.xInterop.com (http://www.xInterop.com).Glad I asked then :) This minimal example is leaking full on. What am I misunderstanding?
That is equivalent to running texture.Dispose() and sprite.Dispose() after drawing as discussed earlier, which solves the leak. But as I understand sfml intends these to be gc'ed properly by dereference.
Being referenced in the scope does not mean much when the GC is running release mode when GC can be very aggressive. GC claim on the object could be as much as early you could think.Ok, but... I don't think it can happen before the object is explicitly used in the function (i.e. before Draw(sprite)).
QuoteBeing referenced in the scope does not mean much when the GC is running release mode when GC can be very aggressive. GC claim on the object could be as much as early you could think.Ok, but... I don't think it can happen before the object is explicitly used in the function (i.e. before Draw(sprite)).
I tested the same code by using "using keyword" for 1 hour using my own version of C# wrapper for SFML generated by NGen++, no memory leak, no crash. The underlying native C++ code is really robust, very stable.
I tested the same code by using "using keyword" for 1 hour using my own version of C# wrapper for SFML generated by NGen++, no memory leak, no crash. The underlying native C++ code is really robust, very stable.
Nobody is arguing your way is not working. We are simply discussing whether SFML is working as it was intended by design (which it appears it is not quite).
Have you had a chance to confirm this Laurent? I'm just wondering whether I should start making workarounds or wait for a fix.
I was trying to help. I am not arguing with you neither, I was simply presenting the fact.I tested the same code by using "using keyword" for 1 hour using my own version of C# wrapper for SFML generated by NGen++, no memory leak, no crash. The underlying native C++ code is really robust, very stable.
Nobody is arguing your way is not working. We are simply discussing whether SFML is working as it was intended by design (which it appears it is not quite).
Have you had a chance to confirm this Laurent? I'm just wondering whether I should start making workarounds or wait for a fix.
I was trying to help. I am not arguing with you neither, I was simply presenting the fact.
Update: The last remaining AccessViolations dissappeared after I started using another texture constructor:Merged in master.
https://github.com/SFML/SFML.Net/pull/60
myl