Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - shawnliu

Pages: [1]
1
DotNet / Re: System.AccessViolation
« on: July 26, 2013, 12:27:28 am »
And I will leave the topic and let you do you own work then.

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.

2
DotNet / Re: System.AccessViolation
« on: July 26, 2013, 12:19:56 am »
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.

3
DotNet / Re: System.AccessViolation
« on: July 23, 2013, 07:48:14 pm »
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 have not read the official version of C# wrapper code yet, I don't know the details, I can not comment.

If you use HandleRef in the class implementation, the object won't get reclaimed by GC during the P/Invoke call. So, you are right, it won't happen before the call, it can happen during the call if HandleRef or similar method is not used to prevent GC from reclaiming the object during the call.

Quote
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)).

4
DotNet / Re: System.AccessViolation
« on: July 23, 2013, 02:50:30 am »
The following is the original code you posted, it does not call Dispose method. Are you expecting the GC to release the texture and sprite object right after each loop with a call to GC.collect(). I don't think GC works that way as I know, I may be wrong though. Referencing and de-referencing object in GC is just a concept, I think its complication is way beyond that.

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.Collect();
}

Secondly, Developers are responsible for calling Dispose or using "using" keyword to call Dispose method. Otherwise, GC calls the finalizer to call Dispose if the pattern is implemented correctly.

If this is a memory issue, how much memory loss have you been seeing by running your code?

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.

5
DotNet / Re: System.AccessViolation
« on: July 23, 2013, 12:07:18 am »
If that is the case you should write code like the following I posted, as I said earlier, it will also prevent GC from reclaiming the objects earlier than you expect.

using(var renderWindow = new RenderWindow(new SFML.Window.VideoMode(200, 200), "I'm a leaker"))
{
    while (true)
   {
        using(var texture = new Texture("nonprogressive.jpg"))
        using(var sprite = new Sprite(texture))
       {
            renderWindow.Draw(sprite);
            renderWindow.Display();
            renderWindow.DispatchEvents();
       }
   }
}
 

6
DotNet / Re: System.AccessViolation
« on: July 22, 2013, 11:35:25 pm »
You can also use Dispose method after you are done with the object if it supports IDisposable interface.

Hi, I will be glad to give you the answer. I am the author of xInterop NGen++ at 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/.

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.


Glad I asked then :) This minimal example is leaking full on. What am I misunderstanding?
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.Collect();
}
 

7
DotNet / Re: System.AccessViolation
« on: July 22, 2013, 11:19:52 pm »
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.

He did say he got AccessViolation exception if I recalled correctly.

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?

8
DotNet / Re: System.AccessViolation
« on: July 22, 2013, 10:48:38 pm »
Hi, I will be glad to give you the answer. I am the author of xInterop NGen++ at 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/.

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.


Glad I asked then :) This minimal example is leaking full on. What am I misunderstanding?
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.Collect();
}
 

Pages: [1]