bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#12478: cat SEGV when I press Ctrl-Alt-SysRq-1 on text console


From: Alan Curry
Subject: bug#12478: cat SEGV when I press Ctrl-Alt-SysRq-1 on text console
Date: Mon, 1 Oct 2012 04:32:21 -0500 (GMT+5)

Rafal W. writes:
> 
> But if Control-4 is sending QUIT signal, why:
> Control-1 does kill the process?
> I've checked again and actually it's not even about the number.
> When I press only: Control-SysRq it kills the process as well.
> Sometimes it happens on press, sometimes on release.

Is your SysRq key also the PrtSc key? It will be if your keyboard is a
descendant of the IBM PC/AT design. With Alt, it's the SysRq key. Without
Alt, it's the PrtSc key. So if your Control-Sysrq combination doesn't include
Alt, then it's really Control-PrtSc and you should call it that instead of
Control-Sysrq which just confusing.

For other keys, the interpretation of modifiers (including Alt) is done in
software. The PrtSc/SysRq key is the only one in which a distinction is made
in hardware. PrtSc and SysRq are different scancodes. This specialness
probably influenced the decision to use SysRq as a magic key for talking to
the Linux kernel.

Now, on to why you got your SIGQUIT. Well, the default keymap for the Linux
console generates ^\ when you press PrtSc. That's not a reason, that's just a
fact. I don't know the reason. The Ctrl-4 thing is, I believe, a matter of
accurate vt100 emulation. At least it's part of a neat pattern. Ctrl-2
through Ctrl-8 generate all the control codes that aren't ^A through ^Z
alphabeticals, in numerical order:

  key     byte   echoprt  ASCII name
  Ctrl-2  0      ^@       NUL
  Ctrl-3  27     ^[       ESC
  Ctrl-4  28     ^\       FS
  Ctrl-5  29     ^]       GS
  Ctrl-6  30     ^^       RS
  Ctrl-7  31     ^_       US
  Ctrl-8  127    ^?       DEL

Notice that one of them, Ctrl-6 for ^^ actually makes sense. The Ctrl-^ is
Ctrl-Shift-6 after all. Perhaps the others were simply built around that one
as a logical extension.

Oops, I got sidetracked. Why does PrtSc generate ^\ on the Linux console? I
don't know. Looking at the historical source code, it seems that it has been
this way since Linux-0.99.10 (June 7, 1993), in which the keyboard driver was
massively overhauled to support loadable keymaps. In 0.99.9 there is this:

                /* Print screen key sends E0 2A E0 37 and puts
                   the VT100-ESC sequence ESC [ i into the queue, ChN */
                puts_queue("\033\133\151");

So in conclusion, the PrtSc ^\ mapping snuck in as part of a large patch that
wasn't supposed to change any defaults, but did. Accident... or sabotage?
Insert your conspiracy theory here. History says Risto Kankkunen did the
loadable keymap patch, so that's who to blame. ChN appears to be:

 * Some additional features added by Christoph Niemann (ChN), March 1993

Whatever the reason behind this annoying ^\, fixing it isn't hard:

# It's too easy to hit PrtSc by accident. mapping it to ^\ hurts!
loadkeys <<'EOF'
keycode 99 = VoidSymbol
EOF

I've had that in my system startup for a long time. Actually it's a bit more
complicated since I have a few other keys I like to remap, but the comment is
exactly as I wrote it at least 15 years ago. (I don't hit PrtSc by accident
much since I got my Happy Hacking keyboard!)

VoidSymbol makes the key do nothing at all when pressed. I suppose you could
map it to "ESC [ i" like it used to be in 0.99.9 if you feel like you must
right this historical wrong.

The remapping has no effect on the usability of the magic SysRq functions,
because they magically bypass the remapping table.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]