# Rubber Ducky Debugging

Oh wow, I’ve just had my first “satori” experience of rubber ducky debugging in a very very long time.

I first tweeted that I ran into a bug in Go, where upon running my code (with go run):

I had a problem where when I ran the same code multiple times, there would be occasions where the program panics. It panics about 40% of the time. And I thought it was a problem with the compilation process.

This then led to a series of conversations between me and the always-helpful Dave Cheney. He led me down a different path of debugging – instead of using go run, I compiled and ran the executable multiple times. The panic happens about 40% of the time again. This ruled out compiler problems.

It ended with him suggesting I email him:

I had rather wanted to get on with my work and not spend a lot of time debugging this. So I sat down and wrote an email and described the problem. The more I described the problem, the more I got the feeling that I may have had everything I thought to be wrong. Until I wrote this line:

…a JSFunctionObject is created, and the pointer is placed in the FnHead node in the AST as the AllocatedValue.

Parts of the SSAForm generator actually accesses the AllocatedValue in the AST while the pointer of the JSFunctionObject is concurrently being set in the AST…

And then it became clear to me what the problem was. VERY VERY clear. I hadn’t even copied and pasted the snippets of code. My design of the program was wrong. And I know how to fix it.

I’m just wow-ing at the fact that the last time I had such a profound satori experience from rubber ducky debugging was years ago, when I was fixing up a machine learning deployment, and I had to explain the bug to someone who had completely no idea about anything programming related. I had to use very simple words and suddenly, it made sense. The same feeling was felt today, albeit with more Go-specific jargon.

I guess sometimes putting your code into english words makes a whole lot of difference.