Fixed the memory leak/coverage processing issue

[tsytsarkin]

This change introduces a fix for issue #62 as well as coverage reporting issue that I encountered while running buzzer on an ARM CPU.

Collected coverage information is getting pushed to a queue, which was processed asynchronously by a separate thread. The coverage addresses are being piped to addr2line utility which returns line numbers. After some profiling, it turns out that this coverage info queue was never drained.

The issue lies in how the call to addr2line utility is made. The exec.Command() call is set up with a list of memory addresses separated by newline chars is being written to the stdin pipe. The problem was caused by the fact that the execution of the program is only kicked off by cmd.Output() call, however the write to the pipe is a blocking call. With large enough input (which appears to be 8k on my system), the pipe runs out of the buffer and blocks further writes awaiting for addr2line to consume some input. Since addr2line is not running at this point, coverage processing is stuck forever.

This results in the coverage queue filling up fast, resulting in eventual OOM crash.

The solution is to move the write call to a separate goroutine to make this a non blocking operation. This will allow the execution to start without waiting for the write to finish. Once write is done, stdin pipe will be closed, which will result in addr2line exiting once it reaches the end of input and cmd.Output() returning the results.

[thatjiaozi]

Hey!

Thanks for taking the time to track and fix this. And sorry for the delay of the review!

Approving and merging changes.

[thatjiaozi]

Apologies, the build is broken due to an issue unrelated to your PR. I am fixing it in #75 and then merging your changes