1

I'm trying to connect Valgrind to GDB. I've written a test code:

#include <stdio.h>

int main()
{
    int x, i;
    for (i=0; i < 10; i++) {
        if (x < 10)
            printf("First\n");
        else
            printf("Second\n");
        x = i * i;
    }
    return 0;
}

I execute valgrind --vgdb-error=0 ./badcode and get

==123460== Memcheck, a memory error detector
==123460== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==123460== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==123460== Command: ./badcode
==123460== 
==123460== (action at startup) vgdb me ... 
==123460== 
==123460== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==123460==   /path/to/gdb ./badcode
==123460== and then give GDB the following command
==123460==   target remote | /usr/lib/x86_64-linux-gnu/valgrind/../../bin/vgdb --pid=123460
==123460== --pid is optional if only one valgrind process is running
==123460==

then I run it in a second terminal window

gdb ./badcode

I followed it by

target remote | vgdb --pid=123460

(the instructions produced by valgrind gave me an incorrect path to vgdb)

So my session in GDB looks like this:

GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
Copyright (C) 2020 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 "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./badcode...
(gdb) target remote | vgdb --pid=123460
Remote debugging using | vgdb --pid=123460
relaying data between gdb and process 123460
warning: remote target does not support file transfer, attempting to access files from local filesystem.
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x0000000004001100 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb) step
Cannot find bounds of current function
(gdb)

Obviously something went wrong. So I close GDB and try one more time:

GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
Copyright (C) 2020 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 "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./badcode...
(gdb) target remote | vgdb --pid=123460
Remote debugging using | vgdb --pid=123460
relaying data between gdb and process 123460
warning: remote target does not support file transfer, attempting to access files from local filesystem.
Reading symbols from /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_core-amd64-linux.so...
(No debugging symbols found in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_core-amd64-linux.so)
Reading symbols from /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so...
(No debugging symbols found in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so...
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x0000000000109162 in main () at badcode.c:7
7           if (x < 10)
(gdb) step
8               printf("First\n");
(gdb) step
__GI__IO_puts (str=0x10a004 "First") at ioputs.c:33
33  ioputs.c: There is no such file or directory.
(gdb)

At first it looks like that everyting is OK, but two steps later GDB breaks at printf function. The full Valgrind log is followng:

==123460== Memcheck, a memory error detector
==123460== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==123460== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==123460== Command: ./badcode
==123460== 
==123460== (action at startup) vgdb me ... 
==123460== 
==123460== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==123460==   /path/to/gdb ./badcode
==123460== and then give GDB the following command
==123460==   target remote | /usr/lib/x86_64-linux-gnu/valgrind/../../bin/vgdb --pid=123460
==123460== --pid is optional if only one valgrind process is running
==123460== 
==123460== 
==123460== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==123460==   /path/to/gdb ./badcode
==123460== and then give GDB the following command
==123460==   target remote | /usr/lib/x86_64-linux-gnu/valgrind/../../bin/vgdb --pid=123460
==123460== --pid is optional if only one valgrind process is running
==123460== 
==123460== Conditional jump or move depends on uninitialised value(s)
==123460==    at 0x109162: main (badcode.c:7)
==123460== 
==123460== (action on error) vgdb me ... 
==123460== Continuing ...
==123460== 
==123460== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==123460==   /path/to/gdb ./badcode
==123460== and then give GDB the following command
==123460==   target remote | /usr/lib/x86_64-linux-gnu/valgrind/../../bin/vgdb --pid=123460
==123460== --pid is optional if only one valgrind process is running
==123460== 
First
First
First
First
First
Second
Second
Second
Second
Second
==123460== 
==123460== HEAP SUMMARY:
==123460==     in use at exit: 0 bytes in 0 blocks
==123460==   total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==123460== 
==123460== All heap blocks were freed -- no leaks are possible
==123460== 
==123460== Use --track-origins=yes to see where uninitialised values come from
==123460== For lists of detected and suppressed errors, rerun with: -s
==123460== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Ubuntu 20.04.3 LTS Valgrind-3.15.0

What can be done to fix this?

Fyodor
  • 25
  • 5
  • 2
    It didn't break at the `printf` function, but you `step` into it. I'm not exactly sure why you think something is wrong, because everything looks fine to me. – ssbssa Jun 21 '23 at 13:34
  • 1
    Except that x is uninitialized before use. – Paul Lynch Jun 21 '23 at 13:40
  • 2
    after connecting gdb to valgrind: enter `break main` and then `c`. – 12431234123412341234123 Jun 21 '23 at 15:26
  • @ssbssa Because it doesn't work at the first time, and at the second time: 1) it can't print `First`; 2) it gives an error message; 3) it can't step to the next line of code. Though if you launch `./badcode` it prints `First` 5 times and `Second` 5 times too. – Fyodor Jun 22 '23 at 03:44
  • @12431234123412341234123 Thanks :D It helped to start gdb on the first try from the beginning of the `main` function but when gdb encounters `printf` function it's all the same: 1) it can't print First; 2) it gives the error message: `__GI__IO_puts (str=0x10a004 "First") at ioputs.c:33` `33 ioputs.c: There is no such file or directory.` 3) it can't step to the next line of code. – Fyodor Jun 22 '23 at 05:21
  • 1) it can't print `First` because you didn't continue the program 2) which error message do you mean? 3) it can't step because you aren't yet in main – ssbssa Jun 22 '23 at 06:24
  • @ssbssa @12431234123412341234123 Oh God, I'm an idiot. I used the `step` command and completely forgot that this command implies that we enter inside the `printf` function. The error was related to the fact that we can't do that. I'm sorry for wasting your time gentlemen. – Fyodor Jun 22 '23 at 09:25

1 Answers1

1

Valgrind-3.15.0 have bug that this output suggests to give to GDB is incorrect: vgdb lives at /usr/bin/vgdb, not where the output suggests.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942532

Suggest use the latest version of Valgrind(now it is valgrind-3.21.0).

Download source code at https://valgrind.org/downloads/ (choice the latest version of Valgrind that V3.21.0). Then compile & install(./configure, make, make install) see at https://valgrind.org/docs/manual/manual-intro.html

I use valgrind-3.21.0 is Ok.

See below:

https://imgur.com/a/9aiWQ2M

Tom
  • 417
  • 3
  • 10
  • The latest version of Valgrind available in the Ubuntu repositories is 3.15.0. At least I can't update it through `sudo apt update`. – Fyodor Jun 22 '23 at 05:27
  • @Fyodor See my updated answer. – Tom Jun 22 '23 at 07:04
  • Nah I updated Valgrind to the 3.21.0 version and unfortunately everything is still in the way it was :( – Fyodor Jun 22 '23 at 09:09
  • @Fyodor You see my use at https://imgur.com/a/9aiWQ2M – Tom Jun 22 '23 at 09:16
  • Oh God, I'm an idiot. I used the `step` command and completely forgot that this command implies that we enter inside the `printf` function. The error was related to the fact that we can't do that. I'm sorry for wasting your time. – Fyodor Jun 22 '23 at 09:26
  • @Fyodor I'm glad that I can help you. If my answer solve your problem,please accept my answer and vote up it. – Tom Jun 22 '23 at 09:33