Lesson

Pay attention to what your tools give you. Sometimes it's exactly what you want.

Story

I have been trying to figure something out inside the Ruby interpreter for a couple of days now. Trying to find something that happens only after hundreds of method executions can be painful; Putting a breakpoint is difficult when the breakpoint will be executed hundreds of thousands of times before it becomes interesting. Conditional breakpoints help, but still aren't perfect, as sometimes formulating the right condition can be difficult.

Mozilla's rr put me in the mind of replay. I even went so far as to find a machine to run it on . Turns out however, Ruby, or our JIT hooked up to Ruby uses a system call unimplemented in rr, and so it didn't work.

While looking for something else though, I noticed the replay family of commands in GDB's help menu. Some googling led to the documentation. Not going to lie though, it really took the tutorial to help me get a handle on it.

What a revelation!

Replay allowed my to very quickly find something I'd spent the day before trying to track down.

reverse-step, you are a dear friend now.

What about rr? As it turns out, for my issue, rr is almost certainly overkill. rr aims to catch non-deterministic failures; where mine is perfectly deterministic. I do hope to spend more time playing with rr though, as it's very cool tech.