Assertion SDL_HashTableEmpty fails on quit with (disconnected) PS4 controller reported in Windows

[samgubernick]

Not sure how much of an issue this is for SDL3 3.2.14 but Windows is reporting that a previously connected PS4 controller is still connected (Bluetooth). When I launch my program, SDL3 is trying to connect it, which fails, and then it disconnects it. Everything's fine till I call SDL_Quit(), which causes the following assertion to fail:

void SDL_SetObjectsInvalid(void)
{
    if (SDL_ShouldQuit(&SDL_objects_init)) {
        // Log any leaked objects
        SDL_IterateHashTable(SDL_objects, LogOneLeakedObject, NULL);
        SDL_assert(SDL_HashTableEmpty(SDL_objects)); // this is failing

I have no idea why Windows is reporting my controller's still connected, so I imagine there's a bigger issue in Windows and this is largely irrelevant, but I wanted to report this in case there's a separate issue in SDL3 where it isn't cleaning up the disconnected controllers correctly.

[slouken]

What object is being leaked?

[samgubernick]

SDL_Gamepad.

I can trigger this consistently on Windows by having the controller connected through Bluetooth and then put the computer to sleep. Windows wakes up and reports the controller is still connected.

[slouken]

I think this is a legitimate leak. The gamepad objects are only opened and closed by the application. Are you doing proper cleanup in this case?

[samgubernick]

Thanks for the response! Yeah, I'm not sure what's causing this issue in SDL. I checked a few places in SDL_gamepad.c but the changes I made there didn't seem to make a difference. I tried the same code in the SDL Snake example and it didn't have this problem, so I went back and checked how I was initializing the gamepad.

From what I can tell, I'm calling SDL_PollEvent() too soon and SDL_IsGamepad() is returning true when it should return false. I was polling the events before I created a window, though I don't recall why. Adding SDL_Delay(500) fixes this problem and SDL_IsGamepad() correctly returns false, so it seems like it's something related to the hash table in SDL.

[slouken]

Can you post a minimal example that reproduces this bug?

[samgubernick]

After I tried to create an example, I found out I couldn't, and moving the event polling code up to the initialization point still causes the issue in my original project even though it's the same as the example I tried to create, so my thinking now is that I have something in an anonymous namespace that's causing this issue. I think we can close this bug report.

[samgubernick]

Ok, I have more information and a suspicion about what's causing this, though I don't know if it's a bug in SDL3 or in ANGLE. If I call glUseProgram() in any compiled file (even if it's never used), or in the entry point itself in unused code, SDL_IsGamepad() will return true if Windows is reporting a Bluetooth controller is connected even when one isn't, which seems like a separate Windows bug.

#include "SDL3/SDL.h"
#include "SDL3/SDL_main.h"
#include "angle/GLES3/gl32.h" // ANGLE doesn't work
// #include "gl/glew.h" // but GLEW does

#ifdef __cplusplus
extern "C"
#endif // __cplusplus
auto SDL_main(int argCount, char * argValues[]) -> int
{
	if (!SDL_Init(SDL_INIT_VIDEO | SDL_INIT_GAMEPAD))
	{
		auto x = 0;
	}
	SDL_Event ev{};
	while (SDL_PollEvent(&ev) == 1 || true)
	{
		if (ev.type == SDL_EVENT_GAMEPAD_ADDED)
		{
			if (SDL_IsGamepad(ev.gdevice.which))
			{
				auto x = 0; // a phantom controller shouldn't trigger this breakpoint
			}
		}
	}
	glUseProgram(0); // this line causes SDL to trigger GAMEPAD_ADDED
	return EXIT_SUCCESS;
}

I'm not at all familiar with ANGLE but I'd guess that it defines something in its functions that's conflicting with SDL3. I tried replacing glUseProgram(0) in this block with glActiveTexture(0) and it causes the same issue. Using GLEW, the same code runs correctly.

To trigger this situation with Windows, I keep Bluetooth turned on, I turn on my PS5 controller, wait for it to connect, then press and hold the PS button to turn it off. Windows will stay say it's connected, and SDL3 will say it's a gamepad if I call a function in ANGLE.

[slouken]

I've seen windows have ghost Bluetooth controllers before, that's an issue unrelated to SDL. Depending on the device, sometimes SDL can detect that it's not real and will remove it after the SDL_EVENT_GAMEPAD_ADDED event. SDL_IsGamepad() should always return true for real gamepads when that event is delivered.

I think this is timing related, and not anything to do with ANGLE. I'm still not sure why you're having a gamepad leak, but everything else you're describing is expected in this situation.

[samgubernick]

Thanks for all the info! The first part seemed like a Windows bug to me, too, and SDL does send the disconnect event following the ghost connection. I don't know if it's immediately following the connection event or on the next cycle.

You're also right that it isn't related to ANGLE. I tried the same test project the next day and it wasn't triggering the issue anymore.

For it leaking the gamepad, calling openGamepad() is returning a null pointer along with an error, and I was originally thinking this was adding the gamepad to the hash table without a way to remove it. I'm not sure if that's still the case, but I don't know how much more help I can be without being able to reproduce this in a sample project.

As a workaround, adding a 250ms delay before polling the events for the first time is on option, but it occurs to me now I can cache the controller number from the connect event and then see if it disconnects before I open it.

Thanks again! Anything I can do to help, let me know. I'll check the SDL gamepad code again later with the context in mind that the controller might've already disconnected when the program calls openGamepad().

[slouken]

Oh, I see the problem. :)