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

Author Topic: segfault/memory curruption risk in SFML Thread class.  (Read 3656 times)

0 Members and 1 Guest are viewing this topic.

deadalnix

  • Newbie
  • *
  • Posts: 45
    • View Profile
segfault/memory curruption risk in SFML Thread class.
« on: November 24, 2011, 09:58:58 pm »
If you spawn a thread, launch it, and immediately delete it, you get intermitent segfault (or worse, memory corruption).

I triggered that with simple code as follow :
Code: [Select]
Thread* t = new Thread(someFunction);
t->Launch();
delete t;


I'm not sure how this is fixable (or not). Maybe by copying the Thread object in the launch function and using that copy ?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Laurent Gomila - SFML developer

deadalnix

  • Newbie
  • *
  • Posts: 45
    • View Profile
segfault/memory curruption risk in SFML Thread class.
« Reply #2 on: November 25, 2011, 10:57:01 am »
Ok, sorry. I did crawl the code and it reveal that the Wait function wasn't working properly on my system. The Thread object could be deleted while the thread was running.

This is definitively a problem of mine. Sorry for the inconvenience, you can close this topic if you wish.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
segfault/memory curruption risk in SFML Thread class.
« Reply #3 on: November 25, 2011, 11:13:31 am »
Why would it be a problem of yours? If Thread::Wait() doesn't work as expected, it's clearly a bug in SFML.
Laurent Gomila - SFML developer

deadalnix

  • Newbie
  • *
  • Posts: 45
    • View Profile
segfault/memory curruption risk in SFML Thread class.
« Reply #4 on: November 25, 2011, 03:39:44 pm »
No, because I'm working on the D bonding, and I did face some tricky bugs relative to threading due to bad interraction between the D runtime and SFML implementation of threads.

After more investigations, this is definitively not SFML's problem, but a bad interraction in low level memory management due to D runtime (memory management in D is thread aware).

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
segfault/memory curruption risk in SFML Thread class.
« Reply #5 on: November 25, 2011, 06:36:05 pm »
By the way, if D has threading functions in its standard library, you shouldn't bind the corresponding SFML classes. Same for networking. These 2 modules are usually left out in bindings.
Laurent Gomila - SFML developer

deadalnix

  • Newbie
  • *
  • Posts: 45
    • View Profile
segfault/memory curruption risk in SFML Thread class.
« Reply #6 on: November 26, 2011, 03:57:39 pm »
The problem is that it is used, for exemple by the audio module. Trass3r had made a workaround for that but it is not very clean and asynchronous. I plan to provide something better to handle that.