A binary compiled with a GCC 4.8.4 containing both C++ and C source files. When starting a GDB with a readnow option, it seems that GDB omits a file name and number information for some C++ compilation units, but when starting the GDB without the given option, in that case the file & line information is there. Without --readnow (gdb) info frame Stack level 0, frame at 0x7fffffffd5b0: rip = 0x14fcc36 in xxxxxxxxxxxxxxxxxxxxxxxxxx::yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy::method_name (/rather/long/long/long/long/long/long/path/to/file:8140); saved rip = 0x14fbf72 called by frame at 0x7fffffffd7b0 source language c++. Arglist at 0x7fffffffd5a0, args: this=0x7fffffffd600, testResults_=... Locals at 0x7fffffffd5a0, Previous frame's sp is 0x7fffffffd5b0 Saved registers: rbx at 0x7fffffffd598, rbp at 0x7fffffffd5a0, rip at 0x7fffffffd5a8 With --readnow (gdb) info frame Stack level 0, frame at 0x7fffffffd5b0: rip = 0x14fcc36 in xxxxxxxxxxxxxxxxxxxxxxxxxx::yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy::method_name(aaaaaaaa::bbbbbbbbbbbb) (); saved rip = 0x14fbf72 called by frame at 0x7fffffffd7b0 Arglist at 0x7fffffffd5a0, args: Locals at 0x7fffffffd5a0, Previous frame's sp is 0x7fffffffd5b0 Saved registers: rbx at 0x7fffffffd598, rbp at 0x7fffffffd5a0, rip at 0x7fffffffd5a8 Tested with GDB 7.7 and 7.12 with identical results. Any attempt to shorten a rather long class/method name didn't change the issue. The problematic frame seems to lack a C++ source language, so could that be a hint for the root cause? A reason for using --readnow option at first place is in this case to read a list of compiled files via a python script, and unless a readnow option is given, a python command gdb.execute("info sources") doesn't return a list of files to be read on demand. With this option the given command returns a full list of source code files used in compilation. The issue prevents front end (Emacs) to show a stepped line from show modules, which can be a bit confusing time to time.