You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using FNA's Texture2D.TextureDataFromStreamEXT which is implemented using SDL_image.IMG_Load_RW in a tight loop on multiple threads concurrently, heap corruption occurs.
To reproduce run the ConsoleApplication4\ConsoleApplication4\bin\Debug\ConsoleApplication4.exe
On 2018-02-16 16:27:28 +0000, Ethan Lee wrote:
Created attachment 3173
C Test Program
I took a look at the test program on Linux and I'm now unsure if that should work anywhere - attached is a C version of the test, with some extras.
When running on Linux without the added SDL_mutex and with more than one thread I get double frees very quickly. With a single thread, or with ADD_MUTEX_SAFETY defined, everything is okay (and it still runs plenty fast).
Where this might vary is with Windows; on Windows this crashes even with ADD_MUTEX_SAFETY defined.
For a quick fix you may just want to use a single thread (doesn't have to be the main thread, I think...), but I'd be interested to know why Windows fails even with locking in place.
On 2018-02-16 17:14:26 +0000, Bart van der Werf wrote:
If the problem is with the malloc mutex than all work needs to be one the same thread, so it would have to be on the mainthread if you intend to also render things.
On 2018-02-16 18:21:23 +0000, Sam Lantinga wrote:
I looked at the PNG loader code, and offhand I don't see why it wouldn't be thread-safe. I haven't looked at libpng though. Where does it crash and get double-free'd?
On 2018-02-16 18:28:16 +0000, Ethan Lee wrote:
Oh weird, I actually got two different results... here's one in IMG_png:
0 IMG_LoadPNG_RW (src=0x7fffe0000af0) at IMG_png.c:409
On 2018-02-16 20:23:03 +0000, Bart van der Werf wrote:
Great to see it resolved :)
reproduction doesn't trigger anymore.
A quick look at the surrounding code shows other non threadsafe refcount actions in for example
SDL_SetPixelFormatPalette
SDL_FreePalette
SDL_InvalidateMap
SDL_MapSurface
or does the contract on those not allow multithreaded access ? or are they non shared resources ?
On 2018-02-17 18:50:32 +0000, Ryan C. Gordon wrote:
(In reply to Bart van der Werf from comment # 7)
A quick look at the surrounding code shows other non threadsafe refcount
actions in for example
Reopening bug to examine.
--ryan.
On 2018-02-17 20:30:45 +0000, Ryan C. Gordon wrote:
These shouldn't need locks--we only need the lock from the previous patch because multiple threads might step on a global linked list--but they probably should use atomic increments.
I'm not sure if we can safely change these things in the public headers, though (grep for "int refcount")...maybe we can just cast &refcount to (SDL_atomic_t *) internally?
--ryan.
On 2018-02-18 17:17:18 +0000, Sam Lantinga wrote:
Let's revisit those other functions for a future release.
Thanks!
The text was updated successfully, but these errors were encountered:
This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:
Reported in version: unspecified
Reported for operating system, platform: Windows 7, x86_64
Comments on the original bug report:
On 2018-02-16 14:42:32 +0000, Bart van der Werf wrote:
On 2018-02-16 16:27:28 +0000, Ethan Lee wrote:
On 2018-02-16 17:14:26 +0000, Bart van der Werf wrote:
On 2018-02-16 18:21:23 +0000, Sam Lantinga wrote:
On 2018-02-16 18:28:16 +0000, Ethan Lee wrote:
On 2018-02-16 18:33:54 +0000, Ethan Lee wrote:
On 2018-02-16 19:56:58 +0000, Ryan C. Gordon wrote:
On 2018-02-16 20:23:03 +0000, Bart van der Werf wrote:
On 2018-02-17 18:50:32 +0000, Ryan C. Gordon wrote:
On 2018-02-17 20:30:45 +0000, Ryan C. Gordon wrote:
On 2018-02-18 17:17:18 +0000, Sam Lantinga wrote:
The text was updated successfully, but these errors were encountered: