stuck in a loop

With uHexen2 v1.5.6, every now and then the game, upon entering menu/console, goes into sort of a loop, where it seems as if the key used to enter menu/console got stuck on autorepeat and the game was repeatedly entering/exiting the menu/console fast enough it never gets exited for long enough to be redrawn. At the same time the menu entering sound it constantly and rapidly restarted.
The only way I found to stop it, once it gets stuck that way, was 'killall -9 glhexen2'.

It seems to happen randomly after running for awhile.

I'm not sure whether the problem lies in Thyrion or elsewhere.

Did anyone else had experienced something similar ?

This feels like the game is somehow crashing (possibly a segmentation fault??) and the reason for the repeated sound is possibly the result of it because it isn't being updated at all. We will try to reproduce this by ourselves, but it would be really helpful if you can capture a backtrace of this. Thanks.

I don't think so.
I've been running uHexen from a terminal - the only extra message printed was "Killed" upon 'killall -9' (note that simply 'killall' isn't enough). On that note - those beautifiers tend to look ugly in an vte-based terminal, but that's just the aesthetics.

The thing that may or may not matter is that somewhen around the hang in the system log there's following message:
usb 2-1.1: unlink qh8-0e01/ffff8801438a4880 start 4 [1/2 us]
ehci-pci 0000:00:1d.0: reused qh ffff8801438a4880 schedule
usb 2-1.1: link qh8-0e01/ffff8801438a4880 start 4 [1/2 us]

It's an usb keyboard.
It might play a role, that I often go "save/reload till succeed" route.

Attaching gdb to such "hung" process doesn't show anything special either, just screen update and sound thread.

The thing that may or may not matter is that somewhen around the hang
in the system log there's following message:
usb 2-1.1: unlink qh8-0e01/ffff8801438a4880 start 4 [1/2 us]
ehci-pci 0000:00:1d.0: reused qh ffff8801438a4880 schedule
usb 2-1.1: link qh8-0e01/ffff8801438a4880 start 4 [1/2 us]

It's an usb keyboard.

Hmm, may it be that SDL is getting stuck somewhere while updating kbd,
because we rely purely on SDL for that? Other than that, I am out of
ideas.

keyboard seems faulty, I think...

Very much possible.

Playing with the source, I got an odd result:
once I've changed in in_sdl.c the lines with SDL_EnableKeyRepeat from SDL_DEFAULT_REPEAT_INTERVAL2 to SDL_DEFAULT_REPEAT_INTERVAL200, the game still gets stuck in menu, but the sound of entering it has time to be played to the end.

So, here's a different idea: is it possible, that upon loading the game not everything gets reinitialized regarding the keyboard and parts of the code see the key as pressed, even though it's been already released ?

Cause I've been able to trigger the problem by simply repeating a few times to press F3 to open load menu, then Enter to load. It might be that while entering the menu triggers the bug, it's already set up to fail once it's loaded.

Playing with the source, I got an odd result:
once I've changed in in_sdl.c the lines with SDL_EnableKeyRepeat
from SDL_DEFAULT_REPEAT_INTERVAL2 to SDL_DEFAULT_REPEAT_INTERVAL200,
the game still gets stuck in menu, but the sound of entering it has
time to be played to the end.

So, here's a different idea: is it possible, that upon loading the
game not everything gets reinitialized regarding the keyboard and
parts of the code see the key as pressed, even though it's been
already released ?

Cause I've been able to trigger the problem by simply repeating a
few times to press F3 to open load menu, then Enter to load. It
might be that while entering the menu triggers the bug, it's already
set up to fail once it's loaded.

Do you mean that Key_SetDest() isn't called from some place where it
actually should be and/or Key_SetDest() isn't doing its job properly?

I dont think linux USB keyboard support is terribly stable.
Years ago, SDL stopped me from adopting a USB keyboard.

If you have a PS2 port, try a PS2 keyboard and see if you can reproduce bug,
or try a fairly different kernel/distro.

Playing with the source, I got an odd result:
once I've changed in in_sdl.c the lines with SDL_EnableKeyRepeat from SDL_DEFAULT_REPEAT_INTERVAL2 to SDL_DEFAULT_REPEAT_INTERVAL200, the game still gets stuck in menu, but the sound of entering it has time to be played to the end.

If changing the SDL repeat interval has any influence, this strongly suggest that it is SDL that believes that the key is still down rather than Hammer of Thyrion itself. What version of SDL are you using?

It has influence, but very little - only on frequency of restarts of the sound of opening the menu. SDL is 1.2.15.

If it's not a stuck state in the game itself, perhaps the game misses SDL_KEYUP under some circumstances - I might be a bit too focused on engine restart on loading a save, but this seems to be the most likely branch of code, given how I trigger the bug.

Another option might be buried in keys.c Key_Event comment - "Should NOT be called during an interrupt!".

A method to test this still flees me.

Well, having a piece of code (and the place to put it), that would compare SDL state (probably based on SDL_GetKeyState ?) with game's state would certainly help with finding the place where things go wrong.

It has influence, but very little - only on frequency of restarts of the sound of opening the menu. SDL is 1.2.15.

Sure, but it indicates that the key repeating that SDL does plays a role; since it has any effect at all, it seems likely that it is SDL that is sending repeat events for your keys. (If it didn't, changing the repeat rate shouldn't have had any effect.)

If it's not a stuck state in the game itself, perhaps the game misses SDL_KEYUP under some circumstances - I might be a bit too focused on engine restart on loading a save, but this seems to be the most likely branch of code, given how I trigger the bug.

Exactly. You could test this by changing the

printf("You pressed %s (%d) (%c)\n", SDL_GetKeyName(sym), sym, sym);

that you uncommented to

printf("You %s %s (%d) (%c)\n", (event.type == SDL_KEYUP ? "released" : "pressed"), SDL_GetKeyName(sym), sym, sym);

And then try to trigger the issue again. My guess is that you won't see (m)any "released" events once you're in the loop.

I've modified the line a little bit more and accidentally stumbled on an interesting result.

printf("You %s %s (%d) (%x)\n", (event.type == SDL_KEYUP ? "released" : "pressed"), SDL_GetKeyName(sym), sym, sym, Key_GetDest());

(%c doesn't make sense for >255, destination looked useful)

In one of the earlier edits I've commented SDL_EnableKeyRepeat lines and forgot about it.

The output was:
- before loop
- Loading game...
You released return...at 0
You pressed F3...at 0
You released F3...at 4
You pressed return..at 4
Client player removed
- in the loop
Loading game...
You pressed F3...at 0

once I restored repeats, the loop was Enter at 0, a single F3 at 0, then F3 at 4 till kill - all of it presses.

So things go wrong once release of Enter gets lost. Looks like a software failure (as, IIRC, if it was a stuck key, releases would be generated too), but hard to tell where.

once I restored repeats, the loop was Enter at 0, a single F3 at 0, then F3 at 4 till kill - all of it presses.

That's what I expected, and it indicates what I suggested: SDL seems to "think" that F3 is still down, and hence keeps sending repeating events for it.

So things go wrong once release of Enter gets lost. Looks like a software failure (as, IIRC, if it was a stuck key, releases would be generated too), but hard to tell where.

Like I said, this looks like a problem at the SDL side. (Btw, I don't understand why you would expect release events for a stuck key; I'd say that as long as SDL believes the key to be down it would make sense for it to not send a release event but keep sending repeating press events, which seems to be happening.)

I'm thinking that this could possible be related to switching unicode handling in a running program, it might be that SDL gets confused by that (though I've never had any problem with that myself). Can you try to comment out all the

SDL_EnableUNICODE(!gamekey);

calls is in_sdl.c and see if you can still trigger the problem?

I don't understand why you would expect release events for a stuck key

Cause if it was physically stuck, keyboard repeat would autorepeat would have kicked in, no ?

Anyway, while due to randomness I can't be 100% sure it fully solves the problem, it's not getting triggered as easily. Actually, it seems that only the call in IN_SendKeyEvents matters (or at least I don't know the conditions needed to trigger it on the other 2 calls).

I don't understand why you would expect release events for a stuck key

Cause if it was physically stuck, keyboard repeat would autorepeat would have kicked in, no ?

Yes, and that would give precisely the results that you are getting, e.g. repeated "pressed" events, without any "released" events in between.

I'm getting the feeling that you think that SDL would would be sending alternating "pressed" and "released" events for a physically stuck key, but you can see for yourself that this isn't the case by simply holding down a random key for a while; you'll see repeated "pressed" events without any "released" events in between, until you actually release the key, at which moment you'll see a single "released" event.

Anyway, while due to randomness I can't be 100% sure it fully solves the problem, it's not getting triggered as easily. Actually, it seems that only the call in IN_SendKeyEvents matters (or at least I don't know the conditions needed to trigger it on the other 2 calls).

Can you try these two cases:

Case 1:

• Comment out the SDL_EnableUNICODE(!gamekey) call in IN_SendKeyEvents().
• Change the SDL_EnableUNICODE(!gamekey) calls in IN_Init() and IN_ReInit() to SDL_EnableUNICODE(0).

Case 2:

• Comment out the SDL_EnableUNICODE(!gamekey) call in IN_SendKeyEvents().
• Change the SDL_EnableUNICODE(!gamekey) calls in IN_Init() and IN_ReInit() to SDL_EnableUNICODE(1).

Is your issue reproducible in any or both of the cases?

Neither of those two cases seems to produce the hang.

You mean that you can reproduce the issue with even after doing the
described changes, yes? If that is the case, I tend to agree with
Sander that the this issue isn't in uhexen2, but is instead triggered
by some unfortunate combination of factors at the SDL level or below.

One last thing to test would be running and old enough uhexen2 version
such as 1.5.1 or 1.5.2 to see whether the issue is reproducible.

I see. So both of the suggested changes eliminate the freeze you've been experiencing. We'll try to work on this and update this thread.