System.AccessViolation

[myl]

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.

[Laurent]

No, I still didn't have to the time to test this, sorry.

[shawnliu]

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.

[shawnliu]

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.

[myl]

I was trying to help. I am not arguing with you neither, I was simply presenting the fact.

I think it's a simple misunderstanding of the meaning of the word "argue", which can be used in two ways; To give reasons or cite evidence in support of an idea (as was used here) or it can be used in an (often) angry manner to express opposing views. Nobody here is mad or angry

And any help here is welcome

[myl]

Hey Laurent!

Any news on this leak issue? Does it have an issue #?

myl

[Laurent]

No. I'm really sorry, I'm so busy with other tasks

[myl]

Hey Laurent

I have some (hopefully) interesting inputs on this subject. I will be implementing and testing fixes and I'd be happy to push back if proven useful.

So there are two problems occurring:
1. AccessViolations are being randomly thrown when library is used heavily (teeth pulling to debug)
Theory: SFML resources are being garbage collected on the gc thread instead of main thread causing some interesting race conditions (I assume SFML backend is not threadsafe?)

I will solve this by marking the objects for disposal in the gc thread and afterwards dispose them on the main thread.

2. I get a heavy mem leak in the minimal code snippet posted earlier on this thread
Theory: Might be fixed by #1 if the leak is caused by AccessViolations. But regardless; finalizers are not guaranteed to be run and this is a perfect usage example for SafeHandles (see http://msdn.microsoft.com/en-us/library/ms228970(v=vs.110).aspx ).

I will add SafeHandles to make sure everything is cleaned up.

What are your thoughts on these approaches?

[myl]

I have implemented the fixes all in ObjectBase, but also a static call in DispatchEvents to ObjectBase.DisposeGarbageCollectedObjects().

The leak is now gone. I get no AccessViolations, but due to their random nature It will take longer to confirm they have truly disappeared.

myl

[myl]

Running tests on around 230 systems (6 different types of hardware configurations) for the past 11 days, I have received AccessViolations 2 times in total. Before my fixes I had about 20 times per day consistently. I can confirm mem leak issues completely gone.

Let me know if you are interested in the implementation.

myl

[krzat]

I'm interested. Fork on Github/Bitbucket would be nice.

[myl]

Sorry for the slow response time. The implementation is up at
https://github.com/myrup/SFML.Net/
Comments welcome

myl

[krzat]

1. Do you think it's necessary to track all SFML objects? I think that only OpenGL objects(Texture, Font, etc.) should be disposed in main thread.
2. Have you tried ConcurrentQueue<T> ? Perhaps it would be more efficient.
3. Maybe ObjectBase and ObjectBaseSafeHandle could be merged together?

[myl]

1. Good point, I'm not sure which objects are threadsafe and which not, It might be worth making another subclass. For now better too many objects disposed than too few!

2. As far as I can tell that's a .Net 4 feature and Sfml should be .Net 2 compatible

3. That would make a lot of sense, I'll be doing that.

[myl]

The merged version is up now, and I created a new pull request for Laurent.

myl