fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

11K
active users

Luke T. Shumaker

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 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.

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 :(