Messages

31

General discussions / Re: Android and iOS ports available for testing

« on: March 14, 2014, 02:44:24 pm »

Hi,

Am I the only one getting an error message telling that 'EGL/egl.h file not found', when building for iOS?

I've looked through the whole post, and it doesn't seem that anyone else have the same problem.

I'm running OSX 10.9 Mavericks, iOS 7 on x64 simulator.

/Kenneth

I have the same issue (and the same system configuration).

I also have this issue on the same system configuration.

32

DotNet / Re: System.AccessViolation

« on: January 26, 2014, 01:42:43 pm »

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

myl

33

DotNet / Re: System.AccessViolation

« on: January 25, 2014, 08:00:53 pm »

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.

34

DotNet / Re: System.AccessViolation

« on: January 25, 2014, 10:36:27 am »

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

myl

35

DotNet / Re: System.AccessViolation

« on: January 20, 2014, 12:16:44 pm »

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

36

DotNet / Re: System.AccessViolation

« on: January 09, 2014, 03:30:02 pm »

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

37

DotNet / Re: System.AccessViolation

« on: January 08, 2014, 04:19:36 pm »

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?

38

DotNet / Re: System.AccessViolation

« on: August 28, 2013, 01:40:34 pm »

Hey Laurent!

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

myl

39

DotNet / Re: System.AccessViolation

« on: July 29, 2013, 11:35:56 am »

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

40

DotNet / Re: System.AccessViolation

« on: July 24, 2013, 10:28:40 am »

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.

41

DotNet / Re: System.AccessViolation

« on: July 23, 2013, 12:51:36 am »

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.

42

DotNet / Re: System.AccessViolation

« on: July 22, 2013, 11:42:02 pm »

I can see why this thread has become a bit confusing, since maybe I should have created a new one when I started asking about memory management. The AccessViolations I experienced are unrelated to the minimal mem leak example. The AccessViolations in my own project didn't occur until I started to make attempts to eliminate leaks by overloading Texture Destructors and Calling Destroy(true) in them. It fixed the leak but caused AccessViolations.

So first things first. Let's try to fix the leak in the minimal code in a healthy way. Ideally without manually disposing textures or manually keeping them alive

43

DotNet / Re: System.AccessViolation

« on: July 22, 2013, 10:16:15 am »

FYI: The unit of the horizontal axis is minutes.

Another FYI: Inserting a texture.Dispose(); after drawing the sprite removes the leakage, but you say this shouldn't be necessary.

44

DotNet / Re: System.AccessViolation

« on: July 22, 2013, 10:09:42 am »

Correction: It seems the mem "leak" that the task manager shows is eventually garbage collected. ANTS shows a private bytes leak that goes up to 1024mb (see screenshot) and after this point, the renderwindow turns white.

45

DotNet / Re: System.AccessViolation

« on: July 22, 2013, 10:00:34 am »

It looks like it should work fine

Great. 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.