34

If I'am debugging files with gdb -tui the source window always becomes messed up. So every time I hit enter I have to immediately type ctrl+L to get rid of this problem, this is how gdb refeshes the window. I am working on tty with gnu screen.

Is there a possibility to automatically refresh gdb in tui mode?
If gdb doesn't have this ability Python could be a solution because gdb is able to source Python files, but I don't know about Python.

This Python snippet works fine in Bash but not inside gdb:

import sys
r = "\033[2J"    # here I try to emulate [ctrl-L]
t = ""
while 1:
    i = sys.stdin.read(1)
    t = t +i
    if i == '\n':
        print(r)

Of course I accept every other language supported by gdb.
Every help is appreciated.

By the way, here is a screencast https://youtu.be/DqiH6Jym1JY that show my problem.

This is the file I used for demonstrating in gdb like the link above show's, mess_up.c

#include <stdio.h>

int main(void){
    //int n = 120;
    int n;
    n = 120;
    char stuff[n+2];

    printf( "Max: %d\n", n );

    printf( "Sizeof int:  %d\n", sizeof(int)  );
    printf( "Sizeof char: %d\n", sizeof(char) );
    printf( "Sizeof n:  %d\n", sizeof n   );
    printf( "Sizeof stuff: %d\n", sizeof stuff  );

    fgets ( stuff , n , stdin );
    printf( "The stuff:\n%s\n", stuff );
    printf( "Sizeof stuff after input = %d\n", sizeof stuff  );

return 0;
}

My actual ncurses version displayed by tic -V is ncurses 5.9.20140118

hdl
  • 1,028
  • 1
  • 9
  • 23
John Goofy
  • 1,330
  • 1
  • 10
  • 20
  • Screen may be your issue. Personally, I find working that working with gdb from within emacs via `M-gdb` works really well, as the integration handles following the source files in a separate window which you give commands to gdb itself. – xxfelixxx Aug 06 '16 at 11:51
  • I have the same problems if I only work on tty without screen. I can't believe gdb works just proper with emacs – John Goofy Aug 06 '16 at 12:03
  • Some examples with images/videos: http://tuhdo.github.io/c-ide.html – xxfelixxx Aug 06 '16 at 12:21
  • 2
    Ooh, this is really overwhelming me that I should keep trying on pressing [ctrl]-[l]. I just know some basic vim commands and my c projects does have at most only 3 or 4 files with source files that have 40 lines at least. This is a little bit to much for refeshing a tty screen. – John Goofy Aug 06 '16 at 13:11
  • 4
    Workaround: (a) create a new terminal window (b) type `tty` in the new window to get the tty name, which will look like `/dev/pts/2` (c) type `sleep 99999` to get the shell out of the way (d) in the gdb tui command window, type `tty /dev/pts/2` (or whatever the tty name is), then `run` as you would normally. – Mark Plotnick Aug 06 '16 at 16:09
  • @MarkPlotnick I've tried this out. But It just wrotes the output to the tty with the sleep command and when a `fgets()` command occurs in gdb it hangs so that I have to hit `ctrl+c`. – John Goofy Aug 06 '16 at 16:39
  • Please enter any tty input for your program by typing it in the new window. – Mark Plotnick Aug 06 '16 at 17:18
  • @MarkPlotnick Yes, I think I followed your instruction. Screen is running in /dev/pts/1, then I open a new window, it's /dev/pts2, there I type sleep n-seconds, while it's sleeping I go to /dev/pts/1, run gdb, there I type tty /dev/pts/2, I load my file, type b main, then run and it looks, that it doesn't mess up anymore the source window. I step through my file, by the way the output is written to /dev/pts/2 with a warning ahead, gdb failed to set controlling, but if I step in gdb to a c function call fgets, gdb hangs. – John Goofy Aug 06 '16 at 19:11
  • I'll try to reproduce your problem. What distribution (name and version number) of Linux are you running? – Mark Plotnick Aug 06 '16 at 20:12
  • Okay, nice, `uname -r` prints `Linux goofy 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28 20:42:32 UTC 2016 i686 i686 i686 GNU/Linux` and `lsb_release -a` prints `No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty`. gdb version is 7.11.1 – John Goofy Aug 06 '16 at 21:08
  • I installed Ubuntu 14.04.5, and stepping up to an fgets does cause gdb to hang, but only because it's waiting for target process's __read_nocancel (called by fgets) to return. Once I type something in the other terminal window, I get a `(gdb)` prompt again. I'm using `layout split`. Do you have a simple program (I'm just using `while(fgets(...)!=NULL) fputs(...)` that causes gdb to hang? – Mark Plotnick Aug 12 '16 at 17:24
  • @MarkPlotnick Yes, I have posted the example source I am using and my actual version of ncurses additionally to my question. I am also using the `layout split`. – John Goofy Aug 12 '16 at 19:36
  • Hi @JohnGoofy, have you solved this issue? I'm facing the same problem on macOS now :( – nalzok Aug 29 '17 at 14:01
  • @SunQingyao No, I didn't. Even with `emacs` I have similarly issues. – John Goofy Aug 29 '17 at 21:27
  • @MarkPlotnick I like your workaround, as it solve the mentioned display issue and it seperates gdb from any console output of the program – antibus Aug 25 '20 at 14:20
  • I lay witness that 5 years later, the situation has no improved whatsoever. If gdb wasn't the only debugger that exists for linux systems, I would swear it's abandonware – lurscher Dec 27 '21 at 13:09

2 Answers2

23

Had the exact same problem. Have you tried GDB user-defined hooks or commands ?

In your ~/.gdbinit or in your session, you can do:

define hook-next
  refresh
end

This will call the refresh command each time you enter the next command or one of its aliases.

Or you can define:

define mynext
  next
  refresh
end

and call mynext instead of next.

Hooks are automatically called whenever a command C is entered and a hook-C exists, that's so cool, I've just discovered that in the docs.

See https://sourceware.org/gdb/current/onlinedocs/gdb/Define.html and https://sourceware.org/gdb/current/onlinedocs/gdb/Hooks.html#Hooks

You can add as many hooks/defines as you want.

hdl
  • 1,028
  • 1
  • 9
  • 23
9

Partially related: I put this in my ~/.gdbinit and it successfully refreshes the TUI after I use c and n, which were the commands usually causing TUI cruft in my case.

define c 
  continue
  refresh
end

define n
  next
  refresh
end
Alex Nibley
  • 111
  • 1
  • 3
  • This is very helpful! Otherwise I have to manually type in refresh every time. So annoying! – jtony May 12 '21 at 11:11