An engine a lot of Doom players use based on SDL is ZDoom (http://zdoom.org). A problem that we’ve been running into is that SDL_PollInput suddenly stops returning any input for an unknown reason. This seemed to start happening in Ubuntu 14.04. The version ZDoom uses is 1.2.15. When the lockup happens, keyboard input is completely lost from SDL_PollInput (it always returns zero from the function that calls it) and the only way to exit the program is to forcefully terminate it from tty… which then messes up the resolution and likely leads to a restart if you play at a non-native resolution.
I attempted to debug it, and from the ZDoom code was able to find that the while loop on SDL_PollInput resulted in events from the keyboard not being available at all after it locks up – however, mouse input is still able to be read.
What is interesting is another Doom port that is separate from ZDoom also uses SDL 1.2.15 and is fine. No lockups occur there.
Therefore: How can I try to figure out what is going on? Is this most likely some code from ZDoom corrupting SDL somehow possibly by leaky pointers? Or is there known driver issues with Ubuntu that could be causing this? Is there any way I could debug it further? I don’t have a problem trying to compile SDL on its own and trying to work through why code is not being accepted, though I’d probably need a guide on how to go about it/where to look. I’ve compiled lots of things on Linux before so I should be able to do most instructions without too much trouble.
Also: Should this possibly go on the bug tracker? I don’t know if it should be ruled out here first before making a ticket.
As to where to begin looking (assuming these files exist on SDL1 branch)… perhaps SDL_events.c would be where I’d start looking. src/video/SDL_video.c their implementation-specific friends (i.e.: cocoa under video/cocoa) are where the platform’s higher-level codebase starts, and SDL_keyboard.c for some of the keyboard implementation details.
In all honesty, though, I’m guessing that ZDoom is mishandling the event loop somewhere down the line for keyboard input. Hard to say without knowing intimate details.
I haven’t used SDL1 in quite some time, but I can’t say I’ve ever had the issue of losing keyboard input, per se…
Cheers,
Jeffrey Carpenter
<@Jeffrey_Carpenter>On 2014/10/ 07, at 18:11, Water wrote:
An engine a lot of Doom players use based on SDL is ZDoom. A problem that we’ve been running into is that SDL_PollInput suddenly stops returning any input for an unknown reason. This seemed to start happening in Ubuntu 14.04. The version ZDoom uses is 1.2.15. When the lockup happens, keyboard input is completely lost from SDL_PollInput (it always returns zero from the function that calls it) and the only way to exit the program is to forcefully terminate it from tty… which then messes up the resolution and likely leads to a restart if you play at a non-native resolution.
I attempted to debug it, and from the ZDoom code was able to find that the while loop on SDL_PollInput resulted in events from the keyboard not being available at all after it locks up – however, mouse input is still able to be read.
What is interesting is another Doom port that is separate from ZDoom also uses SDL 1.2.15 and is fine. No lockups occur there.
Therefore: How can I try to figure out what is going on? Is this most likely some code from ZDoom corrupting SDL somehow possibly by leaky pointers? Or is there known driver issues with Ubuntu that could be causing this? Is there any way I could debug it further? I don’t have a problem trying to compile SDL on its own and trying to work through why code is not being accepted, though I’d probably need a guide on how to go about it/where to look. I’ve compiled lots of things on Linux before so I should be able to do most instructions without too much trouble.
Also: Should this possibly go on the bug tracker? I don’t know if it should be ruled out here first before making a ticket.
The possible problematic code is in I_GetEvent, in MessagePump or in I_CheckGUICapture. Not sure about them.
Jeffrey Carpenter wrote:> Hi,
As to where to begin looking (assuming these files exist on SDL1 branch)… perhaps SDL_events.c would be where I’d start looking. src/video/SDL_video.c their implementation-specific friends (i.e.: cocoa under video/cocoa) are where the platform’s higher-level codebase starts, and SDL_keyboard.c for some of the keyboard implementation details.
In all honesty, though, I’m guessing that ZDoom is mishandling the event loop somewhere down the line for keyboard input. Hard to say without knowing intimate details.
I haven’t used SDL1 in quite some time, but I can’t say I’ve ever had the issue of losing keyboard input, per se…
Cheers,
Jeffrey Carpenter
On 2014/10/ 07, at 18:11, Water wrote:
An engine a lot of Doom players use based on SDL is ZDoom. A problem that we’ve been running into is that SDL_PollInput suddenly stops returning any input for an unknown reason. This seemed to start happening in Ubuntu 14.04. The version ZDoom uses is 1.2.15. When the lockup happens, keyboard input is completely lost from SDL_PollInput (it always returns zero from the function that calls it) and the only way to exit the program is to forcefully terminate it from tty… which then messes up the resolution and likely leads to a restart if you play at a non-native resolution.
I attempted to debug it, and from the ZDoom code was able to find that the while loop on SDL_PollInput resulted in events from the keyboard not being available at all after it locks up – however, mouse input is still able to be read.
What is interesting is another Doom port that is separate from ZDoom also uses SDL 1.2.15 and is fine. No lockups occur there.
Therefore: How can I try to figure out what is going on? Is this most likely some code from ZDoom corrupting SDL somehow possibly by leaky pointers? Or is there known driver issues with Ubuntu that could be causing this? Is there any way I could debug it further? I don’t have a problem trying to compile SDL on its own and trying to work through why code is not being accepted, though I’d probably need a guide on how to go about it/where to look. I’ve compiled lots of things on Linux before so I should be able to do most instructions without too much trouble.
Also: Should this possibly go on the bug tracker? I don’t know if it should be ruled out here first before making a ticket.
It seems that commenting both SDL_EnableUnicode calls in the same file resolves the problem for me and Water.
and I was wrong, because the ‘console’ doesn’t work anymore if I comment both those calls. Apparently, I need to omit just ‘SDL_EnableUNICODE (0)’ to make things work again and fix the problem.
I didn?t know SDL_EnableUnicode existed. Unfortunately, I?m not at all familiar with Unicode. Trying to decipher the event loop logic makes my head start spinning :] At any rate, there?s certainly plenty enough custom event routing going on to where a piece of logic could be inadvertently screwing things up.
It would seem to me that if leaving SDL_EnableUnicode enabled does solve the problem, that the bug is perhaps related to the passing of the unicode field [1] when it is toggled. What is the value range of it when it is enabled and then again with it disabled? More importantly, is it valid data in the context of the higher-level logic that is using the value range? I?m thinking invalid data is being pushed with the event, and this could be interfering with things.