On 8/7/22, Undiscussed Groomed for Male Slavery, One Victim of Many <gmkarl@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.