This bug report was migrated from our old Bugzilla tracker.

Reported in version: HG 2.0
Reported for operating system, platform: Windows 10, x86

Comments on the original bug report:

On 2018-10-01 12:54:27 +0000, Anthony @ POW Games wrote:

I hope I'm doing the right thing here. This worked in 2.0.8:

#include "SDL.h"
int main(int argc, char* argv[]) {
SDL_Init(SDL_INIT_JOYSTICK);
SDL_Window *window = SDL_CreateWindow("Test", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, 500, 500, 0);
bool running = true;
do {
SDL_Event event;
while (SDL_PollEvent(&event)) {
if (event.type == SDL_QUIT)
running = false;
}
} while (running);
SDL_DestroyWindow(window);
SDL_Quit();
return 0;
}

This causes a lock-up after about 5+ seconds of the app losing focus. Observing the app in task-manager, you can see it disappear briefly before coming back as "not responding". Strangely, if you try to observe while running from Visual Studio, the task resumes ok when gaining focus back (something to do with the debugger attachment), but if you run the .exe from file manager, the app will need to be force-closed.

2.0.9 also causes app to restart in Android when certain joysticks are hot-swapped, then permanently breaking the joystick subsystem when the app returns, which didn't happen in 2.0.8. Haven't looked in more detail, but something looks to be broken in the new joystick stuff.

On 2018-10-26 00:37:02 +0000, Sam Lantinga wrote:

Anthony, can you enter a separate bug for the joystick hot-swap issue? I'd like to fix that ASAP for 2.0.9.

Ryan is going to take a look at this bug.

Thanks!

On 2018-10-26 04:27:10 +0000, Ryan C. Gordon wrote:

Okay, so adding some logging to your program to figure out what's up without attaching the debugger...

1. It definitely moves to "not responding" state for me
2. It definitely doesn't move to "not responding" if I don't use SDL_INIT_JOYSTICK
3. It's not locked up! It consistently calls SDL_PollEvent() and returns to the main loop to call my logging code.
4. Adding a renderer to clear the window and present doesn't change things; I was hoping it was Windows complaining that we didn't do any drawing, but it doesn't alter the behavior.

Still digging...

--ryan.

On 2018-10-26 06:22:18 +0000, Ryan C. Gordon wrote:

I bisected this and figured out where this broke:

https://hg.libsdl.org/SDL/rev/00411ca61edb

I haven't dug deeper because I'm about to go to sleep for a few hours, but since this changeset adds a win32 event loop, it's pretty clear what's upsetting Windows in there.

Sam, if you're bored, feel free to take this bug while I'm asleep!

--ryan.

On 2018-10-26 18:51:32 +0000, Ryan C. Gordon wrote:

Okay, so here's what's happening, I think:

Our normal PumpEvents processing checks all windows in the process for new events (using PeekMessage() with a NULL window handle), so I think having a separate event loop for the device change message window upsets the system in some way that I don't fully understand.

We have other message-only windows for other things, and they all just fire from our usual event loop, so I'm assuming it's safe to do the same thing with the device notifications, so long as it all runs on the correct thread.

Just removing the second event loop stops the Not Responding issue, and hotplugging a joystick still correctly alerts the message-only window's windowproc, so I put this patch in:

https://hg.libsdl.org/SDL/rev/67496c3f9626

If we absolutely need that second event loop, feel free to back out this changeset, but from here it appears to be a correct fix.

--ryan.

On 2018-10-26 19:46:45 +0000, Anthony @ POW Games wrote:

Sam, eta on releasing 2.0.9? How long do I have to report on the hot-swapping thing on Android? I need to investigate further.

Ryan, make sure you get enough sleep :)

On 2018-10-27 02:59:46 +0000, Sam Lantinga wrote:

Thanks Ryan!

If there are no show stoppers over the weekend, we're releasing on Monday.

On 2020-10-12 01:17:26 +0000, Anthony @ POW Games wrote:

This bug has come back in 2.0.13 (Sorry Ryan!)

I'm building the DLL with the VS2019 project. When using SDL_INIT_GAMECONTROLLER or SDL_INIT_JOYSTICK subsystem any app will cause a "Not responding" task if the window doesn't receive any input for 5+ seconds. The app doesn't lock and usually resumes normally once mouse / keyboard input is given to the window. I have no joysticks plugged in. Disabling / Enabling background events or HIDAPI doesn't seem to affect it.

On 2020-10-13 16:37:02 +0000, Ozkan Sezer wrote:

Was 2.0.12 good? (out of curiosity..)

On 2020-10-13 17:22:15 +0000, Anthony @ POW Games wrote:

(In reply to Ozkan Sezer from comment # 8)

Was 2.0.12 good? (out of curiosity..)

Yes, the current 2.0.12 DLL from the SDL website works no problem, so it's either something that's changed since then, or it's specific to Visual Studio 2019. Optimisation doesn't make a difference.

On 2020-12-13 06:09:24 +0000, Sam Lantinga wrote:

Can you check to see if this fixes it?
https://hg.libsdl.org/SDL/rev/9b2477ccb1f0

On 2020-12-13 06:11:55 +0000, Sam Lantinga wrote:

Whoops, you'll need this too:
https://hg.libsdl.org/SDL/rev/395ed93b549f

On 2020-12-14 06:56:35 +0000, Anthony @ POW Games wrote:

No, and I think it seems worse now, it's struggling to recover from a "not responding".

Alt-tabbing away from focus almost certainly locks it. It takes a long time before it frees up.

On 2020-12-14 17:05:59 +0000, Sam Lantinga wrote:

Just to see if we're on the right track, can you verify that SDL_StartJoystickThread() is not getting called, and comment out the call to SDL_CreateDeviceNotification() and see if that helps?

Of course I can't reproduce this here. :)

On 2020-12-14 20:56:05 +0000, Anthony @ POW Games wrote:

Let me dig deeper and get back to you. It doesn't happen with the DLL compiled with debug info, which is strange. Sometimes it doesn't happen at all. Will update in a few hours.

On 2020-12-15 02:46:00 +0000, Anthony @ POW Games wrote:

Sam, the conclusion is this: I'm confused :-)

I started from scratch with the test build and the "not responding" is fixed now in the latest HG source. But, SDL_HINT_JOYSTICK_THREAD makes no difference - it's still fixed, which makes no sense yes. If I do SDL_SetHint(SDL_HINT_JOYSTICK_THREAD, "1"), the "not responding" should return, surely?

Also, when I build the DLL with VisualC/SDL.sln project, SDL_JOYSTICK_DINPUT || SDL_JOYSTICK_XINPUT is not defined, so SDL_CreateDeviceNotification() is not compiled anyway?

My head hurts now, so if nobody else is having any problem with this, close the bug - it was 100% an issue in 2.0.13 somewhere along the line though, and if SDL_HINT_JOYSTICK_THREAD is having no affect, maybe it's not needed after all.

On 2020-12-15 02:48:16 +0000, Anthony @ POW Games wrote:

Scratch the part about SDL_JOYSTICK_DINPUT || SDL_JOYSTICK_XINPUT not being defined, they are defined, let me dig a little deeper

On 2020-12-15 03:50:57 +0000, Anthony @ POW Games wrote:

If I back out of your fix https://hg.libsdl.org/SDL/rev/9b2477ccb1f0 from the latest HG, it still works.

Is it possible that some other change in the past 2 weeks already fixed it? That's the only explanation. That, or I'm going mad. Either way, carry on and sorry if I've wasted time :-(

On 2020-12-15 06:10:17 +0000, Sam Lantinga wrote:

I have seen this before, but only when not running under the debugger - and attaching the debugger makes it go away. Does debug vs release build matter?

On 2020-12-15 06:17:42 +0000, Sam Lantinga wrote:

Also, crazy question... have you gotten any Windows updates since you were last able to reproduce it?

On 2020-12-18 06:14:28 +0000, Anthony @ POW Games wrote:

I just compiled a DLL from a source snap-shot from 3 months ago and the bug exists there, which confirms that it is somehow fixed recently.

Since it now works with or without SDL_HINT_JOYSTICK_THREAD, do we need still this hint?

On 2020-12-18 17:05:49 +0000, Sam Lantinga wrote:

I think the hint doesn't hurt and one less thread is a good thing in general.

Is there any chance you can bisect to find where this was fixed?

On 2020-12-19 11:52:35 +0000, Anthony @ POW Games wrote:

I wish I could bisect easily. I'm manually downloading to source and opening up the VC project to compile the DLL, then copying it over to my test project. I'm too dumb / lazy to work out a better way :-)

It was very easy to reproduce the bug in Windows 10 with the source code in the first post here - I don't believe there were any other conditions that influenced it other than a moment in time of SDLs source.

On 2020-12-19 20:06:31 +0000, Sam Lantinga wrote:

Okay, well I was able to reproduce this over the summer, and I bisected all the way back to 2.0.4 and wasn't able to find a good build. I'm not sure code is the only factor here.

In any case, I'm glad it's resolved for you!

On 2020-12-19 20:07:30 +0000, Sam Lantinga wrote:

To clarify, I found a good build back in 2.0.4 and then after I did the bisect it showed the problem on exactly the same build.