"a" key doesn't register in GDB, other letters work fine
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= |
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 |
MikeBC --
What happens if you set LC_ALL=C before you execute gdb ? Code:
# Code:
# -- kjh |
Quote:
|
Quote:
|
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.
|
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 |
I 'smell' `stty`! I **LOVE** strace!
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 |
Quote:
|
The smoking gun, via strace:
Code:
8377 read(0, "a", 1) = 1 |
The solution
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" |
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.
|
All times are GMT -5. The time now is 07:00 PM. |