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 4286 - Joystick subsystem causes "not responding" when app is in the background
Summary: Joystick subsystem causes "not responding" when app is in the background
Status: RESOLVED WORKSFORME
Alias: None
Product: SDL
Classification: Unclassified
Component: joystick (show other bugs)
Version: HG 2.0
Hardware: x86 Windows 10
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-01 12:54 UTC by Anthony @ POW Games
Modified: 2020-12-19 20:07 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Anthony @ POW Games 2018-10-01 12:54:27 UTC 
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.
Comment 1 Sam Lantinga 2018-10-26 00:37:02 UTC 
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!
Comment 2 Ryan C. Gordon 2018-10-26 04:27:10 UTC 
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.
Comment 3 Ryan C. Gordon 2018-10-26 06:22:18 UTC 
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.
Comment 4 Ryan C. Gordon 2018-10-26 18:51:32 UTC 
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.
Comment 5 Anthony @ POW Games 2018-10-26 19:46:45 UTC 
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 :)
Comment 6 Sam Lantinga 2018-10-27 02:59:46 UTC 
Thanks Ryan!

If there are no show stoppers over the weekend, we're releasing on Monday.
Comment 7 Anthony @ POW Games 2020-10-12 01:17:26 UTC 
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.
Comment 8 Ozkan Sezer 2020-10-13 16:37:02 UTC 
Was 2.0.12 good? (out of curiosity..)
Comment 9 Anthony @ POW Games 2020-10-13 17:22:15 UTC 
(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.
Comment 10 Sam Lantinga 2020-12-13 06:09:24 UTC 
Can you check to see if this fixes it?
https://hg.libsdl.org/SDL/rev/9b2477ccb1f0
Comment 11 Sam Lantinga 2020-12-13 06:11:55 UTC 
Whoops, you'll need this too:
https://hg.libsdl.org/SDL/rev/395ed93b549f
Comment 12 Anthony @ POW Games 2020-12-14 06:56:35 UTC 
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.
Comment 13 Sam Lantinga 2020-12-14 17:05:59 UTC 
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. :)
Comment 14 Anthony @ POW Games 2020-12-14 20:56:05 UTC 
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.
Comment 15 Anthony @ POW Games 2020-12-15 02:46:00 UTC 
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.
Comment 16 Anthony @ POW Games 2020-12-15 02:48:16 UTC 
Scratch the part about SDL_JOYSTICK_DINPUT || SDL_JOYSTICK_XINPUT not being defined, they are defined, let me dig a little deeper
Comment 17 Anthony @ POW Games 2020-12-15 03:50:57 UTC 
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 :-(
Comment 18 Sam Lantinga 2020-12-15 06:10:17 UTC 
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?
Comment 19 Sam Lantinga 2020-12-15 06:17:42 UTC 
Also, crazy question... have you gotten any Windows updates since you were last able to reproduce it?
Comment 20 Anthony @ POW Games 2020-12-18 06:14:28 UTC 
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?
Comment 21 Sam Lantinga 2020-12-18 17:05:49 UTC 
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?
Comment 22 Anthony @ POW Games 2020-12-19 11:52:35 UTC 
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.
Comment 23 Sam Lantinga 2020-12-19 20:06:31 UTC 
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!
Comment 24 Sam Lantinga 2020-12-19 20:07:30 UTC 
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.