"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 ---
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 
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:
.
(gdb) help wh
Set the height of a specified window.
Usage: winheight  [+ | -] <#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 
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:
.
(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 
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:
.
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+deb

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

[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?


On 2014年10月29日 14:10, ishikawa wrote:
> "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 
> This 

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

[Pedro Alves]

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


___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb

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

[ISHIKAWA,chiaki]

Dear Pedro Alves,

> 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

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




___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb

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

[Pedro Alves]

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


___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb