[spam][crazy][log] gdb, thread local, libgit, instruction pointet

Undiscussed Groomed for Male Slavery, One Victim of Many gmkarl at gmail.com
Sat Aug 6 21:27:34 PDT 2022


On 8/7/22, Undiscussed Groomed for Male Slavery, One Victim of Many
<gmkarl at gmail.com> wrote:
> ok, this time i stepped into the first call and it turns out the
> return statement is throwing an exception inside it, and gdb's "step"
> and "nexti" commands do not step into the exception handler, instead
> continuing. the iterator theoretically steps to the next value and the
> breakpoint is hit again
>
> i'm guessing that i had let it run too many times last time, and some
> bug caused an overflow and memory corruption, maybe

To clarify here, after posting this email thread, this was the first
time gdb would let me inspect the data as the system was running.
Previously I was getting errors regarding inability to access thread
local data, or to set a breakpoint on the next instruction inside code
without debugging symbols.

I experienced the looping that appears to now be from a thrown
exception (and that looks like what should be happening, the thrown
exception) even when I was using the "si" and "ni" commands to single
step through individual assembly instructions.

Previously, when I used "si" to step into library code that _does_
have debugging symbols, gdb would show ?? for the function name. This
time, it let me step into the call and review the exceptional case a
little.

This is why I consider memory corruption. Not sure what from, the code
in the loop is not complex.

I have these old gdb interactions in my scrollback buffer, likely,
although I have since resized the window containing the tmux session.


More information about the cypherpunks mailing list