Console unusable after running SDL app

Question

When certain SDL-based programs (e.g. prboom, dosbox) are run from the console (not X) and terminate abruptly for some reason (e.g. killed or segfaults), the screen locks up; It just goes black, and remains black until you reboot.

This is in contrast with the hello_video and hello_triangle demos which return the console to its original state even if they are terminated abruptly.

What exactly is going wrong here, and is there a way to recover it without rebooting?

I have observed this in Debian Squeeze. I do not know if other OSes are affected.

Edit: I should clarify only the console (HDMI/RCA output, USB keyboard) is affected, not ssh connections (which continue to work fine.)

@Jivings no, but (1) Ability to reboot is not the problem: I can issue a shutdown command from a ssh connection and (2) I am looking for a solution that does not require rebooting. — finnw, Jun 13 '12 at 09:00
Oh ssh. Well in your ssh prompt you could kill the X server and restart. Or restart the runlevel. — Jivings, Jun 13 '12 at 09:01
@Jivings, the X server was never running in the first place. The runlevel can be changed but this has no effect on the console. — finnw, Jun 13 '12 at 09:04
I have more experience with SDL now, where did you get the package from? — Jivings, Jun 14 '12 at 12:15
@Jivings, http://packages.debian.org/squeeze/libsdl1.2debian — finnw, Jun 14 '12 at 12:32
@Jivings: It is there: It's the "armel" version (and it's what you get if you do apt-get install dosbox etc.) — finnw, Jun 14 '12 at 12:55
I'm blocked on the same problem. Did anybody found a solution? — , Jan 12 '13 at 16:26

score 6 · Answer 1 · answered Jun 21 '12 at 18:15

6

This is almost certainly a bug in the graphics driver. It sounds as though SDL is initializing the graphics API, at which point the graphics driver takes over the display. Because you killed SDL it never ran the code to deinitialize the graphics API, and so it is just sitting waiting for graphics commands which will never come.

This indicates a badly designed graphics API, but because the entire thing is proprietary there is no way to know and no way to fix it.

(I have observed similar behaviour on a PC where SDL "grabs" the mouse pointer and does not ungrab it if it crashes or is killed, but never with the display.)

answered Jun 21 '12 at 18:15

Alistair Buxton

804
7
17

1

SDL has a "parachute" that it deploys normally to clean up even in the case of segfaults so something's not right still. – Flexo Jun 23 '12 at 23:52
The parachute will only catch SIGSEGV, not SIGKILL. – Alistair Buxton Jun 27 '12 at 09:36
That's interesting, I'll have to try sending SIGKILL to one of the GLES2 demos and see what happens. – finnw Jun 27 '12 at 13:39
I'm developing an SDL app in 2017 and there still seems to potentially be a bug with using CTRL-C to quit an SDL app. I had the problem that SDL and terminal input would gradually become unresponsive when I was testing the app, repeatedly running it and quitting with CTRL-C. I've found that if I quit the app properly from within the SDL app then I don't ever have the problem. – Paul Slocum Jun 01 '17 at 04:23

score 1 · Answer 2 · answered Jan 19 '17 at 01:31

I know this is a very old question, but I was running into a similar problem to this when running Mupen64Plus via EmulationStation. My console would show up fine, but the keyboard would be totally unresponsive until I performed a reboot.

The problem was that the keyboard was remaining in RAW mode after the program terminated. The solution was to add the following line to the end of the shell script that ran it: kbd_mode -a. This resets the keyboard to XLATE mode and enables it to work again.

While this doesn't resolve the "black screen" portion of the problem, I'm guessing there must be an analogous way to reset the console framebuffer to get video back.

Console unusable after running SDL app

2 Answers2

Linked