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

Author Topic: System.AccessViolation  (Read 23252 times)

0 Members and 1 Guest are viewing this topic.

myl

  • Jr. Member
  • **
  • Posts: 68
    • View Profile
    • Email
Re: System.AccessViolation
« Reply #30 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.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: System.AccessViolation
« Reply #31 on: July 24, 2013, 11:18:52 am »
No, I still didn't have to the time to test this, sorry.
Laurent Gomila - SFML developer

shawnliu

  • Newbie
  • *
  • Posts: 8
    • View Profile
    • Email
Re: System.AccessViolation
« Reply #32 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.
Shawn Liu, Author of xInterop NGen++, A C# Wrapper Generator for native C++ DLL at http://www.xInterop.com.

shawnliu

  • Newbie
  • *
  • Posts: 8
    • View Profile
    • Email
Re: System.AccessViolation
« Reply #33 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.
Shawn Liu, Author of xInterop NGen++, A C# Wrapper Generator for native C++ DLL at http://www.xInterop.com.

myl

  • Jr. Member
  • **
  • Posts: 68
    • View Profile
    • Email
Re: System.AccessViolation
« Reply #34 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 :)

myl

  • Jr. Member
  • **
  • Posts: 68
    • View Profile
    • Email
Re: System.AccessViolation
« Reply #35 on: August 28, 2013, 01:40:34 pm »
Hey Laurent!

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

myl

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: System.AccessViolation
« Reply #36 on: August 28, 2013, 01:46:37 pm »
No. I'm really sorry, I'm so busy with other tasks :(
Laurent Gomila - SFML developer

myl

  • Jr. Member
  • **
  • Posts: 68
    • View Profile
    • Email
Re: System.AccessViolation
« Reply #37 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?


myl

  • Jr. Member
  • **
  • Posts: 68
    • View Profile
    • Email
Re: System.AccessViolation
« Reply #38 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

myl

  • Jr. Member
  • **
  • Posts: 68
    • View Profile
    • Email
Re: System.AccessViolation
« Reply #39 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

krzat

  • Full Member
  • ***
  • Posts: 107
    • View Profile
Re: System.AccessViolation
« Reply #40 on: January 20, 2014, 06:33:37 pm »
I'm interested. Fork on Github/Bitbucket would be nice.
SFML.Utils - useful extensions for SFML.Net

myl

  • Jr. Member
  • **
  • Posts: 68
    • View Profile
    • Email
Re: System.AccessViolation
« Reply #41 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

krzat

  • Full Member
  • ***
  • Posts: 107
    • View Profile
Re: System.AccessViolation
« Reply #42 on: January 25, 2014, 06:49:17 pm »
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?
SFML.Utils - useful extensions for SFML.Net

myl

  • Jr. Member
  • **
  • Posts: 68
    • View Profile
    • Email
Re: System.AccessViolation
« Reply #43 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.

myl

  • Jr. Member
  • **
  • Posts: 68
    • View Profile
    • Email
Re: System.AccessViolation
« Reply #44 on: January 26, 2014, 01:42:43 pm »
The merged version is up now, and I created a new pull request for Laurent.

myl