Byron Nevins: Byron's Pointless Ramblings

I've been scratching my head over this bug for a LONG time and I finally nailed it down today. Here is the non-executive (i.e. wirehead) summary: I call an external process and parse the stdout that the process generates. I have dozens of such calls in the code. The other calls are relatively slow (seconds to minutes). This one is very fast -- it just returns a chunk of text with its version information.

The bug is that the process returns an empty string instead of the expected 1000 bytes or so.

Clues:

• The bug always appears on UNIX -- never on Windows.
• The bug never appears when stepping through the debugger

  The fact that the code worked perfectly in the debugger and always broke without the debugger was perplexing. And then I thought -- "what's the difference?". TIME!! When I'm stepping through the code it is like geological time passing as far as the code is concerned. So I added a 2 second sleep after calling the process but before reading the saved stdout. Instantly, the bug went away. So what must have been happening is that the process returned from the waitFor() but the threads that are reading the process's output and error streams didn't get the text yet. My final solution will probably be to put in a poll -- while(myprocess.getStdout().length() == 0) ; // hang around a bit

  I came up with a much better fix. I already had this:

  process.waitFor()

  Two threads are running draining stdout and stderr. They eventually get a null back from the read's they are doing in a (blocking) loop, and they exit. So I just added these 2 lines:

  outThread.join();
  errThread.join();