Recent searches
Search options
past me: I love finding segfaults, because it's the one time that things are unambiguously a bug and we don't have to spend any time discussing "maybe it's user error".
me today: I'm not sure if this is really a bug. I mean yes, it segfaulted. Yes, it specifically said "This is a bug, please report it." But I might just be holding it wrong?
So I'm definitely abusing GDB by writing some Python to bypass internals.
But also, I can't get it to do that specific segfault again?
So I did end up finding a reliable reproducer (but quite large: with a specific binary and a specific .py file loaded, `run`, wait about 3 seconds `cr list` (which is a command from the .py), `cr list`, `call (void)cr_gdb_nop_intr()`, `stepi`; I have no idea what it is about that sequence that triggers it).
My #GDB had been compiled with `--enable-source-highlight`; changing that to `--disable-source-highlight` makes the crash go away. But nothing in the stacktrace looked related to that. #gnu
I am now faced with the question: Now that I know how to get a GDB without the crash, do I return to what I was working on, or do I try to get a bugfix into GDB?
(Or at least track down the bug far enough that I have information to put in a bug report?)
@lukeshu I'd check if it is still an issue in the latest version of gdb compiled from git. I've spent too much time debugging issues that have already been fixed upstrean
@its_a_me Good reminder! But indeed the crash still happens on git master :(