Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDL_PollEvent does not return after restarting the program a few times #3069

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments

SDL_PollEvent does not return after restarting the program a few times #3069

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments


Copy link

@SDLBugzilla SDLBugzilla commented Feb 11, 2021

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: 2.0.9
Reported for operating system, platform: Windows 10, x86_64

Comments on the original bug report:

On 2018-11-17 03:32:16 +0000, Daniel wrote:

Created attachment 3499
Code I used to test the bug.

I have created an almost barebones program using the latest stable release of SDL 2.0.9. The program has a main loop with an event loop which calls SDL_PollEvent. In my tests, after the program has launched and closed about 15 times, SDL_PollEvent no longer returns, so the program just locks up on the main thread.

I have also tested the same code on many unstable builds of SDL available on The program does not lock up on versions SDL-4024 or before, but it does lock up on versions SDL-4025 or after. From what I can tell, the only difference between SDL-4024 and SDL-4025 is that the following line of code is uncommented from SDL_config_macosx.h and SDL_config_windows.h: "//#define SDL_JOYSTICK_HIDAPI 1"

As I said above, I have tested the issue on many builds which includes the latest stable release. Here is the list of unstable builds I tested with:
4253, 4200, 4170, 4100, 4070, 4030, 4025, 4024, 4022, 4018, 4015, 4014, 4013, 4012, 4011, 4010, 3979, 3925

I have attached the c++ code I was using to test each version.
I am sure I missed some information that might be needed.


On 2018-11-17 04:30:31 +0000, Sam Lantinga wrote:

What's the stack trace where it's hung up?

You're not initializing the joystick subsystem, so that shouldn't be a factor here.

On 2018-11-17 04:51:52 +0000, Daniel wrote:

I am not exactly sure if this is the stack trace you are looking for, but here is the call stack when the application locks up.

On 2018-11-17 08:43:45 +0000, Sam Lantinga wrote:

Can you build SDL yourself so you can get symbols for that stack trace?

On 2018-11-17 09:42:01 +0000, Daniel wrote:

(In reply to Sam Lantinga from comment # 3)

Can you build SDL yourself so you can get symbols for that stack trace?

Here is the stack trace with symbols. I used the code currently available on the repo.

It appears to get stuck on hid_enumerate() in the HidD_GetSerialNumberString function call.

On 2018-11-19 13:01:48 +0000, Daniel Gibson wrote:

Can you try if it works if you pass SDL_INIT_JOYSTICK to SDL_Init()?

In it turned out that SDL_PumpEvents() calls SDL_JoystickUpdate() (which then eventually causes hid_enumerate() to be called) even if joysticks are not enabled.
However, if they are not enabled SDL_HIDAPI_discovery.m_bCanGetNotifications is false and thus every three seconds the HID devices are updated (instead of only when a corresponding event arrives).

On 2018-11-19 13:19:30 +0000, Daniel Gibson wrote:

If this indeed is related to my problem discussed in discourse, I could fix that by modifying SDL_PumpEvents() to only call SDL_JoystickUpdate() if joysticks are actually enabled, like

/* Check for joystick state change */
if (SDL_WasInit(SDL_INIT_JOYSTICK) && (!SDL_disabled_events[SDL_JOYAXISMOTION >> 8] || SDL_JoystickEventState(SDL_QUERY))) {

I wonder if the same should be done a few lines below for the sensors, i.e. adding a SDL_WasInit(SDL_INIT_SENSORS) to the if-condition before SDL_SensorUpdate();

I also don't know if SDL_WasInit() is indeed the best/most efficient way to test this, or if maybe some other flag should be checked at the beginning of SDL_JoystickUpdate() instead (and then return immediately there), but apart from these details, we need to make sure that SDL_JoystickUpdate() doesn't try to enumerate HID devices if joysticks are disabled.

On 2018-11-19 14:31:21 +0000, Daniel wrote:

Passing SDL_INIT_JOYSTICK, with and without other conditionals, into SDL_Init() does not appear to fix the issue. Previously, the window would appear, then the program would hang on SDL_PollEvent with a white and unresponsive window after a few launches. With SDL_INIT_JOYSTICK, the window never even shows up because the program hangs on SDL_Init() after a few launches.

Note: After the program freezes once, I am unable to get it to work correctly again unless I reboot my machine. Adding/removing SDL_INIT_JOYSTICK from SDL_Init() after the program has started freezing does not appear to do anything either.

On 2018-11-19 16:18:38 +0000, Daniel Gibson wrote:

Ok, that indicates that on your machine everything is a lot more broken then on mine - here hid_enumerate() sometimes takes 5seconds which is a lot longer than usual, but apparently on your machine it locks up completely and even manages to get some internal state of windows/the driver/the device so confused that you need to reboot before they can be queried again.

So this definitely needs more investigation by someone who knows about such things - I don't, but to me it seems like it could totally be a hardware or driver or maybe windows problem. Of course it /could/ still be that SDL does something wrong when querying the devices, but even if it does, being executed in an unprivileged process it shouldn't be able to screw things up in a way that need a reboot.

I created a new bugreport for my issue: # 4391

On 2018-11-20 05:19:35 +0000, Sam Lantinga wrote:

Can you check to see if this change helps?


On 2018-11-20 05:20:54 +0000, Sam Lantinga wrote:

Also, can you get a list of USB devices that are connected, and try unplugging them all and then add them one by one until this breaks? This seems to be a bug in the Windows USB driver system and it would be nice to know what's triggering it.


On 2018-11-20 06:08:22 +0000, Daniel wrote:

I will work on testing that change and getting a list of USB devices. I will also test the bug on my laptop, once using 2.0.9, and another time using the change you suggested.

On 2018-11-20 07:13:38 +0000, Daniel wrote:

The fix you suggested does appear to have worked. I have not been able to reproduce the bug on my desktop or laptop. Switching between my desktop and laptop(running out-of-date windows) did not appear to make a difference while testing the latest stable release(2.0.9) or the fix you suggested.
Version 2.0.9 caused the program to freeze on both machines. The fix appeared to have worked on both machines.

If you are unfamiliar with Windows, the grayed out items are inactive devices.
USB Devices on Desktop:
USB Devices on Laptop:

Let me know if you want information on a specific device.

On 2018-11-20 13:28:59 +0000, Daniel Gibson wrote:

Does that commit also fix the issue for you if you use SDL_INIT_JOYSTICK?

If I recall correctly, just querying the devices once on startup can already permanently freeze your program, and of course SDL should also work with joysticks enabled.

On 2018-11-20 13:59:09 +0000, Daniel wrote:

The issue still exists while using SDL_INIT_JOYSTICK. One thing that did change, however, is that I no longer have to reboot my machine to get the program to work again after switching from using SDL_INIT_JOYSTICK to not using it.

Previously if the program froze while using SDL_INIT_JOYSTICK, the program would continue to freeze even without using SDL_INIT_JOYSTICK. If the program froze while not using SDL_INIT_JOYSTICK, the program would also continue to freeze when using it.

On 2018-11-20 15:51:39 +0000, Sam Lantinga wrote:

From the device list it looks like you don't have any active USB devices - is that right? It shouldn't be possible for the Windows driver to hang with no devices on the USB bus.

If you do have USB devices connected, can you remove them and see if that fixes the issue for you, and if no, remove them one at a time to see if it's a particular device that's causing the problem?

On 2018-11-20 15:55:19 +0000, Daniel Gibson wrote:

Note that this could even be keyboard/mouse (if they're connected via USB), so in that case use a different one - ideally use an old PS/2 keyboard, if you've still got one and your mainboard still has a connector for that.

(though maybe for testing you could start your test app with just keyboard or mouse and the other one disconnected)

On 2020-03-21 04:00:18 +0000, Sam Lantinga wrote:

Can you check to see if this is fixed in the latest SDL snapshot?


@SDLBugzilla SDLBugzilla added bug waiting labels Feb 11, 2021
@slouken slouken removed the bug label May 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants