[SOLVED] "a" key doesn't register in GDB, other letters work fine

MikeBC · 11-17-2016, 08:31 AM

I've got a bit of an odd problem here. In GDB, my "a" key does not register. I've tried it in the console and in X11, and neither method allows me to type the letter a. Interestingly, capital A registers fine. For example, if I try and type "breakpoints," I only get "brekpoints." I thought it might be a problem with the GDB frontend, so I tried to use DDD as a front-end. The same problem occurs there! The only difference is that in DDD I can actually see the "a" as I type it. If I type in "breakpoints" and hit Enter, I get "Undefined info command: "brekpoints"." So, the a is not getting actually passed to GDB correctly.

I figure this is a problem with my key mappings, but I'm unsure of how to fix the problem. Has anyone had this problem before? What'd you do to fix it? It's so strange- "a" works fine in other programs, but not GDB.

Edit: I ran "dumpkeys" and +a is mapped to keycode 30.

Edit 2: Here's the output from locale.
➜ ~ locale
LANG=en_US
LC_CTYPE=en_US
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE=C
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=

jmccue · 11-17-2016, 04:42 PM

very odd, your setup seems to match mine and gdb works fine for me. I am on 14.2 x64 no multilib

I have see problems with the letter 'a' in rxvt on a non-Linux OS, turned out rxvt had issues, Xterm was fine on that OS. On Slackware no issues with rxvt.

John

kjhambrick · 11-18-2016, 06:48 AM

MikeBC --

What happens if you set LC_ALL=C before you execute gdb ?

Code:

#
# only set LC_ALL for the gdb session ...
#
LC_ALL=C gdb ...

Or try the Nuke 'em from Orbit Option

Code:

#
# as the 7-bit ANSI UNIX gods intended :)
#
export LC_ALL=C
gdb ...

HTH

-- kjh

MikeBC · 11-18-2016, 09:40 AM

Quote:

Originally Posted by jmccue

very odd, your setup seems to match mine and gdb works fine for me. I am on 14.2 x64 no multilib
John

I'm on 14.2 i686. It's a head scratcher for sure. I figured it HAD to be some sort of problem in my terminal, but the problem persists whether I'm using xterm, the standard Linux console, st, you name it. It almost seems like it's a problem in GDB itself and how that software handles keyboard input.

MikeBC · 11-18-2016, 09:46 AM

Quote:

Originally Posted by kjhambrick

MikeBC --

What happens if you set LC_ALL=C before you execute gdb ?

That is a good idea! I gave both methods a shot and the results were the same. I think the next step might be digging through the GDB source code to see if I can figure out how input is captured. It'd be great if I could find another piece of software that has this same problem so that I can look for similarities. I know that mutt, mc, top, emacs and cpan work fine. One would think that some of these programs might have the same problem.

MikeBC · 11-18-2016, 09:48 AM

Interestingly, if I pipe an "a" into gdb from the terminal, it works. Of course, that's no way to actually debug a program so this is useless to me, but it's an interesting piece of the puzzle.

kjhambrick · 11-18-2016, 11:29 AM

Yikes !

I am stumped, except maybe two more ...

I always run `screen` on remote systems when doing OS updates just in case I lose my ssh connection in the middle of 'something important'.

The screen program seems to do all sorts of wonderful things (

and some not so wonderful things

) to my terminal ...

Anyhow ...

Speaking of ssh: I wonder if: ssh -p 22 localhost and then try gdb ?
And screen ... Does your a-key work if you invoke gdb from within a screen session ?

About out of ideas here

-- kjh

Jjanel · 11-18-2016, 12:34 PM

Maybe try as a *different user* (e.g. sudo su -). Look into:

stty -a
strace -f -o myfile gdb
a
Ctrl-D
tail -111 myfile|more
Look for *like*: write(1,"(gdb) ",6)=6 ... read(0,"a",1)=1

Code:

29659 ioctl(0, SNDRV_TIMER_IOCTL_STATUS or TIOCSWINSZ, {ws_row=25, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
29659 ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
29659 ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
29659 ioctl(0, SNDCTL_TMR_STOP or SNDRV_TIMER_IOCTL_GINFO or TCSETSW, {B38400 op ost isig -icanon -echo ...}) = 0
29659 ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
29659 write(1, "(gdb) ", 6)             = 6
29659 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
29659 poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=0, events=POLLIN}] , 3, 0) = 0 (Timeout)
29659 poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=0, events=POLLIN}] , 3, -1) = 1 ([{fd=0, revents=POLLIN}])
29659 rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT ALRM TERM TSTP TTIN TTOU], [], 8) = 0
29659 rt_sigaction(SIGINT, {0xb76fbfa0, [], 0}, {0x81d97f0, [INT], SA_RESTART}, 8) = 0
29659 rt_sigaction(SIGTERM, {0xb76fbfa0, [], 0}, {0x81d9830, [TERM], SA_RESTART} , 8) = 0
29659 rt_sigaction(SIGHUP, {0xb76fbfa0, [], 0}, {0x81d9660, [HUP], SA_RESTART}, 8) = 0
29659 rt_sigaction(SIGQUIT, {0xb76fbfa0, [], 0}, {0x81d9690, [QUIT], SA_RESTART} , 8) = 0
29659 rt_sigaction(SIGALRM, {0xb76fbfa0, [], 0}, {SIG_DFL, [], 0}, 8) = 0
29659 rt_sigaction(SIGTSTP, {0xb76fbfa0, [], 0}, {SIG_DFL, [TSTP], SA_RESTART}, 8) = 0
29659 rt_sigaction(SIGTTOU, {0xb76fbfa0, [], 0}, {SIG_DFL, [], 0}, 8) = 0
29659 rt_sigaction(SIGTTIN, {0xb76fbfa0, [], 0}, {SIG_DFL, [], 0}, 8) = 0
29659 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
29659 rt_sigaction(SIGWINCH, {0xb76fb4f0, [], SA_RESTART}, {0x81113a0, [], 0}, 8) = 0
29659 read(0, "a", 1)                   = 1
29659 write(1, "a", 1)                  = 1

MikeBC · 11-18-2016, 04:27 PM

Quote:

Originally Posted by Jjanel

Maybe try as a *different user* (e.g. sudo su -).

A-ha! That did the trick! If I log in as root or as a freshly-created user, the a key works fine. It must be something in my login scripts that is screwing this up. I'm going to comb through them and see if I can spot the problem.

MikeBC · 11-18-2016, 04:34 PM

The smoking gun, via strace:

Code:

8377  read(0, "a", 1)                   = 1
8377  write(2, "\7", 1)                 = 1

When I hit a, I get \7?! Weird. I'm going to mark this as solved and as I find out more about this, I will add my findings to the thread. Thank you Jjanel! I had forgotten all about strace. It's a wonderful program.

MikeBC · 11-18-2016, 04:53 PM

OK, so here's what I did to fix this problem.

First off, I'm using zsh. When I tried to change my shell to bash, I encountered the problem on the shell as well as in GDB. Something gets loaded in bash that doesn't in zsh. I ended up loading a session of bash inside my zsh session, with strace attached. I noticed that bash loads .inputrc. When I removed that, the a key worked again everywhere.

Now, I have no idea what in my .inputrc was causing this problem, but here's the entire contents of that file:

Code:

gpg-agent --daemon --enable-ssh-support --write-env-file "${HOME}/.gpg-agent-info"

# set path
PATH=/usr/local/sbin:/usr/sbin:/sbin:/home/mike/bin:$PATH

It all seems pretty innocuous to me. Anyway, things are good now.

MikeBC · 11-18-2016, 04:56 PM

I deleted each part of the .inputrc file and tested after each part, and the culprit is that first line with the gpg-agent. I have no clue how that command would cause the "a" key not to work in some programs and not others, but there you have it.