gdb stopped working

trying to track down a segmentation fault. When I used to try to debug rack with gdb (gdb ./Rack, run-d) when it crashed I would get a line number. Now I just get :frowning_face:

Thread 36 received signal SIGSEGV, Segmentation fault. [Switching to Thread 31588.0x4e60] 0x0000000012303de5 in ?? ()

trying to back trace gives: Backtrace stopped: previous frame identical to this frame (corrupt stack?)

I suspect some setting got changed, but not sure where to look

Some years ago at work, for gdb core files on linux x86_64 (and MIPS as well) I had great success with the ultra-newest versions of gdb whenever such “corrupt stack” situations occurred. But there were some weird situations (especially on MIPS) that e.g my self-built gdb 8.0 would refuse to work while my self-built 7.8 would play the stacktrace fine. And also the corner cases where indeed the core file was totally messed up.

The problem you are facing I believe is twofold: Both the refusal of gdb to show a stacktrace, as well as the fact that Windows does not create core files. If possible could you reproduce the same issue on Linux? Maybe there with a core file present more clues could come up.

You probably don’t get a line number because the stack is corrupt. The crash is likely happening after the code has managed to jump or return to somewhere outside of your code. Buffer overruns, or writing to uninitialised pointers are likely culprits.

Unfortunately there were quite a few times where different gdb versions would allow for a perfect stacktrace replay - even if the core info seemed totally corrupt. I am highlighting this again here since I’ve seen it happen many times in linux systems.