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