"wh" command without argument to gdb in Emacs shell buffer == utter confusion

[ishikawa]

"wh" command without argument to gdb in Emacs shell buffer

Running gdb in Emacs's shell-mode buffer and then issueing "wh"
without argument by mistake causes GDB to get hung (without no visible
activity) [or rathr print long blank lines without prompt!?]

I am perplexed as to what is going on as I uncover a few things along
the way.

Below, a  log is excerpted.

---

Note 1: I am NOT using Emacs's gdb-mode when this happens.  I type
"gdb" as an ordinary shell command within the Emacs's shell buffer.

Note 2: Background.

In the old days, "wh" would be considered a shorthand for "where"
command.  But today there is "winheight" command and "wh" is regarded
as a shorthand for it.  An old timer like me types "wh" as a shorthand
for "where" without argument, and noticed this strange problem.

After a few days of pondering and trying to fix various issues like
missing shared library symbols, etc., finally I got curious and typed
"help wh" and found out about this "winheight" command. So I was
typing "winheight" command instead of "where" all along.

Note 3: If I use gdb in an ordinary terminal screen, say, without
argument and type "wh" to gdb prompt,

$ gdb
gdb> wh

I get a small popup window, and in this case, it says, "No source
available"
and the usage help is printed to the original tty console where gdb
prompt appears, and prompt returns.
[I mistook this popup window as a X window, but no, it seems
it is a text rectangle created by termcap library or similar! This is
a source of confusion on my analysis. This confusion is in this writeup.]

That is good.

In emacs's shell-buffer usage, there is no indication of either (no
window, no help message to the prompt. Well, control-C does not seem
to work, but please read the excerpt log #2 at the end.)

To wit, here is the log from within Emacs's shell buffer.
The first run of gdb simply prints the help message for "wh" and quits.
The second run gets hung after I type "wh".

[Ugh! No, as I write this message, I got still wiser and hit "C-MC-J" to
this seemingly hung gdb and I got gdb> prompt again.  What is going
on? More in the Log #2 at the end.]


Log 1:
--- begin quote ---
address@hidden:/home/ishikawa$ gdb
GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) help wh
Set the height of a specified window.
Usage: winheight <win_name> [+ | -] <#lines>
Window names are:
src  : the source window
cmd  : the command window
asm  : the disassembly window
regs : the register display

(gdb) quit
address@hidden:/home/ishikawa$ gdb
GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) wh




                                                                               
                                                                        


---

As you can see, control-C won't interrupt gdb.
I have to kill gdb from another console.
[But please read the log #2 excerpt at the end. It seems that there is
another process running in a mixed manner in this terminal.]

This is a major usability issue.

Merely typing a command without an argument should not
render gdb unusable.

Yes, I think emacs might be setting up a strange environment for
gdb, but gdb code should be ready for failing to open a X window,
etc.

TIA

My Environment:
gdb --version
GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
address@hidden:/home/ishikawa$ emacs --version
GNU Emacs 24.4.1
Copyright (C) 2014 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
address@hidden:/home/ishikawa$ uname -a
Linux debian-vbox-ci 3.2.0-4-686-pae #1 SMP Debian 3.2.57-3+deb7u2 i686
GNU/Linux

OS Issue:
The particular log was obtained under 32-bit version of Debian
GNU/Linux, but the problem also happens under 64-bit Debian GNU/Linux
as well.

Emacs version: I checked this happens with the latest version of emacs
(24.4.1) noted above ANDd slightly older emacs 24.3 also. So I
think this is a gdb issue.

---
Log 2: Ugh. I wonder what is goin on?!

I got wiser, and typed "C-JC-M" on a hunch to the seemingly
hung state.

Then the following gdb prompt showing up again(!)

(I am not removing the C-M (CR) from the log since it may be
important.  But when I typed "help wh" to the gdb prompt, see what I
got!?


(gdb)


(gdb)help wh
---Type <return> to continue, or q <return> to quit---
(gdb)q

==== My Idea
After this
---Type <return> to continue, or q <return> to quit---
I realize that gdb probably is running a pager to show the source file
or something from my guess based on "No source available" message seen
with
gdb invokved from ordinary tty terminal. Then I realized and checked
that this "pop up window" is an text box created by termcap or something.

Hmm... So somehow gdb is trying to create a text box using
termcap inside a dumb EMACS emulator or what?

I am totally confused and have no idea for suggested fix.

Since Emacs's shell mode buffer has the following environment variables,

(The following sentence was written when I thought gdb used window for
X to create a popup. If not, then I am not sure how to change gdb's behavior
and not break
Emacs's gdb mode...)

I wonder if gdb can use the setting of DISPLAY
over other setup. It is as if gdb today looks at EMACS and TERM
setup and invokes a pager or something for showing "source window"?
and does not use a separate window as it would have used when
it is invoked on the ordinary terminal window.

Agah, now I see that the "separate window" is drawn using a
termcap and similar library and is not a true X window (!?)
Hmm... I still think that gdb can be a little cleverer.

Environment Variable:
>From within EMACS (X-window version)
$env | grep DISPLAY
DISPLAY=:0.0
$ env | grep TERM
TERM=dumb
TERMCAP=
COLORTERM=gnome-terminal
$ env | grep EMACS
EMACS=t
INSIDE_EMACS=24.4.1,comint
$

TIA