GDB zeigt kein vollständiges Backtrace an

Question

Ich schreibe einen CHIP-8-Interpreter in C++ mit SDL2. Der Quellcode ist https://github.com/robbie0630/Chip8Emu. Es gibt ein Problem, bei dem ein Segmentierungsfehler mit this ROM auftritt. Ich habe versucht, das Problem mit GDB zu debuggen, aber wenn ich bt eintippe, zeigt es eine unvollständige Stapelüberwachung an, die nur die ersten zwei Funktionen zeigt, die es mir ermöglichen, das Problem effektiv zu diagnostizieren. Wie bekomme ich eine vollständige und nützliche Stack-Trace?

EDIT: Wenn ich bt laufen, GDB zeigt dies:

#0 0x0000000101411a14 in ??() 
#1 0x0000000000406956 in Chip8_CPU::doCycle (this=0x7fffffffc7b0) at /my/home/code/Chip8Emu/src/cpu.cpp:223 
#2 0x0000000000402080 in main (argc=2, argv=0x7fffffffe108) at /my/home/code/Chip8Emu/src/main.cpp:152 

Dieses nutzlos ist, weil ?? nichts anzeigt, und die Linie 223 von cpu.cpp ist ein Funktionsaufruf.

EDIT 2: Ich lief valgrind auf dem Programm, und hier ist die Ausgabe:

==11791== Conditional jump or move depends on uninitialised value(s) 
==11791== at 0x406BA0: Chip8_CPU::doCycle() (cpu.cpp:215) 
==11791== by 0x4020EF: main (main.cpp:152) 
==11791== 
==11791== Jump to the invalid address stated on the next line 
==11791== at 0x101411A74: ??? 
==11791== by 0x4020EF: main (main.cpp:152) 
==11791== Address 0x101411a74 is not stack'd, malloc'd or (recently) free'd 
==11791== 
==11791== 
==11791== Process terminating with default action of signal 11 (SIGSEGV) 
==11791== Access not within mapped region at address 0x101411A74 
==11791== at 0x101411A74: ??? 
==11791== by 0x4020EF: main (main.cpp:152) 
==11791== If you believe this happened as a result of a stack 
==11791== overflow in your program's main thread (unlikely but 
==11791== possible), you can try to increase the size of the 
==11791== main thread stack using the --main-stacksize= flag. 
==11791== The main thread stack size used in this run was 8388608. 
==11791== 
==11791== HEAP SUMMARY: 
==11791==  in use at exit: 7,827,602 bytes in 41,498 blocks 
==11791== total heap usage: 169,848 allocs, 128,350 frees, 94,139,303 bytes allocated 
==11791== 
==11791== LEAK SUMMARY: 
==11791== definitely lost: 0 bytes in 0 blocks 
==11791== indirectly lost: 0 bytes in 0 blocks 
==11791==  possibly lost: 4,056,685 bytes in 36,878 blocks 
==11791== still reachable: 3,770,917 bytes in 4,620 blocks 
==11791==   suppressed: 0 bytes in 0 blocks 
==11791== Rerun with --leak-check=full to see details of leaked memory 
==11791== 
==11791== For counts of detected and suppressed errors, rerun with: -v 
==11791== Use --track-origins=yes to see where uninitialised values come from 
==11791== ERROR SUMMARY: 12 errors from 3 contexts (suppressed: 0 from 0) 
Killed 

EDIT 3: Ich lief wieder GDB, diesmal GfxDraw beobachten, und ich bemerkte dies geschah:

Old value = (void (*)(array2d)) 0x1411bc4 
New value = (void (*)(array2d)) 0x101411bc4 
Chip8_CPU::doCycle (this=0x7fffffffc7a0) at /home/robbie/code/Chip8Emu/src/cpu.cpp:213 
(gdb) cont 
Continuing. 

Thread 1 "Chip8Emu" received signal SIGSEGV, Segmentation fault. 
0x0000000101411bc4 in ??() 

So irgendwie GfxDraw wird zu einem ungültigen Funktionszeiger geändert. Ich kann jedoch nicht herausfinden, wo es geändert wird.

Answer 1

Nach ein paar Monaten habe ich das Problem endlich erkannt. Einige bösartige CHIP-8-Programme machen unzulässige Speicherzugriffe auf den Grafikspeicher, die außerhalb der Grenzen des Arrays liegen, und korrumpieren Eigenschaften der CPU (wie GfxDraw). Ich habe dieses Problem behoben, indem ich mit at auf den Grafikspeicher zugegriffen und std::out_of_range Fehler ignoriert habe. Es scheint für jetzt zu funktionieren, also erkläre ich es zur Lösung.