I'm writing an unwinder in Python. If I try to get the register "pc" from the pending frame object that is passed to my unwinder, gdb crashes: ../../binutils-gdb/gdb/regcache.c:796: internal-error: regcache_cooked_read_value: Assertion `regnum < regcache->descr->nr_cooked_registers' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) [answered Y; input not from terminal] This is a bug, please report it. For instructions, see: <http://www.gnu.org/software/gdb/bugs/>. ../../binutils-gdb/gdb/regcache.c:796: internal-error: regcache_cooked_read_value: Assertion `regnum < regcache->descr->nr_cooked_registers' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) [answered Y; input not from terminal] I think either this should work, or it should throw a python exception.
I also observed this with the OpenJDK unwinder. I think it may be caused by the same sequence of events I reported in BZ 19288.
*** Bug 20128 has been marked as a duplicate of this bug. ***
I wonder whether the patch at: https://sourceware.org/ml/gdb-patches/2016-08/msg00239.html ends up fixing this too.
Turns out it doesn't. The problem is that pending_framepy_read_register uses get_frame_register_value which only works for raw registers. Kevin's working on addressing that, by using value_of_user_reg. However, that exposes another recursion problem. Reading such a register value produces a lazy lval_register value, and such registers need to store their frame's id in VALUE_FRAME_ID. And that then calls into get_frame_id of the pending frame. The problem is that in the Python unwinder API, it's the job of the sniffer hook to return back the frame's ID to gdb. Since we're inside the sniffer hook still, there's no way for GDB to know the frame id yet... This is a mismatch between the Python unwinder API and GDB's internal unwinder APIs... The solution we're currently attempting is to make VALUE_FRAME_ID store the frame id of the _next_ frame instead (which would be the sentinel frame in this case of the current frame), and then adjust value_fetch_lazy to use frame_unwind_register_value directly on the next frame instead of using get_frame_register_value. Similarly for other VALUE_FRAME_ID users.
I believe this is fixed now: https://sourceware.org/ml/gdb-patches/2016-11/msg00015.html Closing.