Is this a gdb bug?

Question

I was playing around with a simple program (see below) and I came across behavior that did not seem correct. I ran the program with gdb as shown below, and it does not seem to read the passed arguments to func correctly, for instance it says b=21845, and even says . Is there an explanation for this?

I am running this on a MacBook Pro, 2.3 GHz 8-Core Intel Core i9, MACOS 13.1 (22C65). I compiled the program with: g++ -std=c++2a test.cpp -g -lpthread -lstdc++fs -o test I got the DBG debugger from https://marketplace.visualstudio.com/items?itemName=coolchyni.beyond-debug. It is GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1, configured as x86_64-linux-gnu. I am using visual studio code.

Code: test.cpp

#include <iostream>

void func(int b, int &c)
{
  std::cout << b <<" and " << c<< std::endl;
  
}

int main()
{
  
  int num2 = 4;
  int &num3 = num2;
  func(num2, num3);
  
  return 0;
}

GDB Run

Starting program: /home/es927/exper/test 

Breakpoint 1, main () at test.cpp:10

10        int num2 = 4;

(gdb) s

11        int &num3 = num2;

(gdb) s

12        func(num2, num3);

(gdb) s

func (b=21845, c=<error reading variable>) at test.cpp:4

4       {

(gdb) s

5         std::cout << b << " and " << c << std::endl;

(gdb) s

4 and 4

6       }

(gdb) s

main () at test.cpp:14

14        return 0;

(gdb) s

15      }

(gdb) c

Continuing.

[Inferior 1 (process 1235898) exited normally]

I was expecting the values of the passed arguments when stepping after code line 12.

Answer 1

This is fully expected behavior. This kind of parameter behaviour is described in the gdb manual - 10.3 Program Variables (emphasis mine):

Warning: Occasionally, a local variable may appear to have the wrong value at certain points in a function—just after entry to a new scope, and just before exit.

Thus, the easiest solution is to just step once more into the actual function block scope and use info local. The manual also goes on to talk about methods for trying to mitigate this wrong value behavior. Unfortunately, I was not able to reproduce the weird values you were having (in WSL with gcc-11.3.0 and gdb-13.1) so I was unable to verify these methods.

All things considered, I would not worry about this kind of debugger behavior too much. For example, these uninitialized parameter values are every day for the Visual Studio's debugger, even to the point of making it hard to debug single line functions.

Edit: Based on the comments and more findings, here are some other things you can try:

• As @jwdonahue pointed out that, you might have an issue with an old gdb version (eg. gdb --version). You can try updating gdb with the package manager or just build a newer gdb from source and replace the system gdb with that.
• Try to use gdb specific debugging information with -ggdb. There is also a -g3 option, but that changes very little compared to the default level 2.