Thread 2 hit Breakpoint 1, S::find_zone (this=0x7fffe49b8c10, labels=std::vector of length 376816642480893855, capacity 377483531152624935 = {...}) at s.cc:255 255 { (gdb) n 256 auto const zone_iter = boost::find(zones_, labels); (gdb) up #1 0x0000000000896aae in D::process_query (this=0x6180000000d8, work_item=std::unique_ptr<wi> = {...}) at w.cc:169 169 auto const * const zone_ptr = params.find_zone(parts); (gdb) p parts $1 = std::vector of length 2, capacity 10 = {0x619000020161 "abc", 0x619000020165 "de"} (gdb) p params $2 = (const S &) @0x61f000000c58: {ttl_ = {__r = 42}, ...} (gdb) down #0 S::find_zone (this=0x61f000000c58, labels=std::vector of length 2, capacity 10 = {...}) at s.cc:256 256 auto const zone_iter = boost::find(zones_, labels); (gdb) show version GNU gdb (GDB) 8.2.1 It doesn't just happen when stopped by a breakpoint. The same behavior can be seen when stepping into a function. The values displayed on entry should be the same as after the up/down. It seems like GDB can't decode the stack while at the entry point of the function, only after the execution reaches the first statement. This is GDB 8.2.1, built from the tarball on Ubuntu 18.04.2 LTS with gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1) $ uname -a Linux mymachine 4.15.0-52-generic #56-Ubuntu SMP Tue Jun 4 22:49:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux