SFML community forums

Help => System => Topic started by: deadalnix on November 24, 2011, 09:58:58 pm

Title: segfault/memory curruption risk in SFML Thread class.
Post by: deadalnix 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 ?

Title: segfault/memory curruption risk in SFML Thread class.
Post by: Laurent on November 25, 2011, 08:01:53 am

http://www.sfml-dev.org/forum/viewtopic.php?p=36367#36367

Title: segfault/memory curruption risk in SFML Thread class.
Post by: deadalnix 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.

Title: segfault/memory curruption risk in SFML Thread class.
Post by: Laurent 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.

Title: segfault/memory curruption risk in SFML Thread class.
Post by: deadalnix 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).

Title: segfault/memory curruption risk in SFML Thread class.
Post by: Laurent 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.

Title: segfault/memory curruption risk in SFML Thread class.
Post by: deadalnix 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.