Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

73 views
Skip to first unread message

ishikawa

unread,
Oct 29, 2014, 2:31:17 AM10/29/14
to bug...@gnu.org
"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 ---
ishikawa@debian-vbox-ci:/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
ishikawa@debian-vbox-ci:/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/>.
ishikawa@debian-vbox-ci:/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.
ishikawa@debian-vbox-ci:/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


ishikawa

unread,
Oct 29, 2014, 6:59:31 AM10/29/14
to bug...@gnu.org, Ishikawa
Hi,

After searching through WWW to find out when this "winheight"
command appears, I realize that
I was lucky that the versions of gdb I used before
was compiled in such a manner that I do not
have this TUI command set of gdb.
It seems that TUI mode was already in gdb at least by 2002.

In searching WWW for "gdb TUI debian" I came across
an interesting post to Debian's bug report database.
It seems that I am hitting this "mess" caused by not so perfect handling of
libcurse style
drawing/refresh by gdb?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706407
xfce4-terminal: ncurses-mess with gdb in TUI-mode

To reproduce the case in the Debian bug report,
I ran
gdb /bin/ls
(gdb) wh
(gdb) run

in xterm and I can confirm that the source window which is shown by "wh"
does not get cleaned up well enough and so the result of /bin/ls output is
mixed in the xterm screen resulting in a mess.

In the case of xterm, the next (gdb) prompt is still visible, so
people can say, gdb is broken in refreshing the screen well, but
in the case of Emacs's shell window, the prompt is not even visible and
I think the pager, [why another page is invoked is a mystery to me],
(oh, can it be related to .gdbinit?)
is eating the character (^c), etc. which a confused user may
type into the shell buffer.

So this problem may not be Emacs per se, but could be a
symptom of a larger broken handling of character console
by gdb.
Either
- it may not be using termcap and similar library correctly,
- it may not notice that the terminal at hand does not support
all the required functionality by gdb's TUI mode, and
behave erratically, OR
- the terminal's termcap entry, etc. is not quite correct and
gdb sends out incorrect character sequence that resulted
in the mess reported here and the Debian bug report database.

(Or the mess may have resulted from the combination of all.)

At least you don't have to run emacs and run shell-mode to experience a problem
by running gdb in xterm
and type the following command to see the messed up terminal screen.

gdb /bin/ls
wh
run

The above command sequence
can show a screen redraw problem (well, minor version) which may
prompt someone to find the root cause of the issue.
Hopefully, that can lead the root cause of the problem I originally mention.

TIA

PS: I wonder though, short of re-compiling gdb by disabling tui feature,
is there a way to suppress TUI command and let gdb recognize "wh" as "where"
command?

Pedro Alves

unread,
Oct 29, 2014, 8:12:08 AM10/29/14
to ishikawa, bug...@gnu.org
On 10/29/2014 05:10 AM, ishikawa wrote:
> $ env | grep TERM
> TERM=dumb
> TERMCAP=

Right, we can reproduce this on the terminal with just:

$ TERM=dumb gdb -q -nx
(gdb) wh

I'm working on a fix that will make GDB error out instead
of hanging, like:

$ TERM=dumb gdb -q -nx
(gdb) wh
Cannot enable the TUI: terminal doesn't support cursor addressing.
(gdb)

Thanks,
Pedro Alves


ISHIKAWA,chiaki

unread,
Oct 29, 2014, 10:41:45 AM10/29/14
to pal...@redhat.com, bug...@gnu.org
Dear Pedro Alves,
Thank you very much for your debugging effort.

After learning about TUI, I thought disabling this feature
based on the terminal capability would be one way to handle this issue.
So your patch would be very much appreciated.

Still being puzzled why I didn't realize this TUI feature for such a
long time. It is not clear when TUI is enabled in Debian Package.
It is possible it was not enabled even in the current release and only
enabled in Jessie (experimental and the would be mainline release in the
next release cycle).

Thank you again.

Best Regards,
Chiaki Ishikawa




Pedro Alves

unread,
Oct 29, 2014, 11:08:07 AM10/29/14
to ISHIKAWA,chiaki, bug...@gnu.org
On 10/29/2014 02:41 PM, ISHIKAWA,chiaki wrote:

> Thank you very much for your debugging effort.

No problem. I use the TUI myself every day.

FYI, the bug is fixed on mainline now:

https://sourceware.org/ml/gdb-patches/2014-10/msg00798.html

> Still being puzzled why I didn't realize this TUI feature for such a
> long time. It is not clear when TUI is enabled in Debian Package.
> It is possible it was not enabled even in the current release and only
> enabled in Jessie (experimental and the would be mainline release in the
> next release cycle).

No idea here. The TUI has been in GDB for ages.

Thanks,
Pedro Alves


0 new messages