We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2020 - Race condition between SDL_PushEvent and SDL_SetEventFilter.
Summary: Race condition between SDL_PushEvent and SDL_SetEventFilter.
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: events (show other bugs)
Version: HG 2.0
Hardware: All All
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-07 11:43 UTC by Rainer Deyke
Modified: 2019-10-14 15:38 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Deyke 2013-08-07 11:43:49 UTC
SDL_PushEvent is supposed to be thread-safe.  However, SDL_PushEvent reads the event filter function pointer (SDL_EventOK) that is written by SDL_SetEventFilter.  This is a race condition that could lead to SDL_PushEvent reading a corrupted pointer if SDL_SetEventFilter is called in the main thread while SDL_PushEvent is called in another thread.
Comment 1 Sam Lantinga 2013-08-07 12:12:20 UTC
How does the race condition manifest in your program?
Comment 2 Philipp Wiesemann 2015-10-14 20:33:51 UTC
SDL_PushEvent() is not really thread-safe but SDL_PeepEvents() should be. If user events need to be added from another thread then SDL_PeepEvents() can be used (it does not access the filters and gestures).
Comment 3 Sylvain 2017-10-24 19:53:32 UTC
similar issue with bug 2107
Comment 4 Sylvain 2019-10-14 15:38:41 UTC
Was fixed here: https://hg.libsdl.org/SDL/rev/6d17410edb75