Closed unvariant closed 7 months ago
Thank you for your report. It was fixed. See 34bed12bfe7f234a7398f0f4ef92864240460673.
I don't know the cause, but it seems that a memory reference error occurred when executing a step inside ExecAsm(...).exec_code()
(called from get_gs()
). This memory reference error was occurring on the gdb side and was not a GEF problem. I think it's probably failing to trace the frame from ebp
. I thought this error could be ignored, so I wrapped it in try-except
and the problem seems to be resolved.
Thanks! I love your fork of gef, it is pretty amazing.
When connecting to a remote gdbserver under i386 or using pwntools
gdb.debug
, if a breakpoint is hit gdb gets stuck at that address and continue/nexti/stepi all fail to properly go to the next instruction.The issue seems to be the slow path of the
get_gs()
function which retriggers the breakpoint when attempting to read the gs base address to show as part of the registers context pane. Removing the slow path fixes the issue in my testing.