New blog post: Debugging an evil Go runtime bughttps://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ …
-
-
Replying to @marcan42
I wonder if rr would have helped here?
@rocallahan@khuey_1 reply 0 retweets 1 like -
If it doesn't make assumptions about stack layout or use of libc, then quite likely. I was going to mention reverse execution debugging as a powerful approach that might've worked but I wasn't sure of any examples.
1 reply 0 retweets 1 like -
Ah, no. It emulates a single core machine. Wouldn't repro the failure, it requires multicore (not just multithread).
3 replies 0 retweets 1 like -
rr's chaos mode plays with thread scheduling enough that it might be able to tease out the bug anyways.
1 reply 0 retweets 0 likes -
The orq is atomic on a single core CPU, it's never going to race anything because it's a single instruction and you can't interrupt a thread in the middle of the orq.
1 reply 0 retweets 0 likes -
Isn't this just a straightforward out of bounds write? Why does racing matter at all?
1 reply 0 retweets 0 likes -
Ah I see, ok. Good times.
1 reply 0 retweets 0 likes -
That's *really* nasty and is something we wouldn't be able to reproduce. This is excellent debugging work. The hash-based recompilation trick is awesome.
1 reply 0 retweets 1 like
Thanks :). I'm putting rr into my toolbox, though, it looks really neat! Reversible debugging is something I knew about but it was always too much effort to get to work in the past.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.