Haguichi crashes with too many networks

[Eduardo rocha]

- With more than 70 networks with 20 machines each, Haguichi freezes on startup.

- Traced down the problem, and found the problem to be in method Command.ReturnOutput:
  - If the result of a "hamachi list" command is too long, the Process.WaitForExit will not return before timeout, and everything freezes.

[Eduardo rocha (joao-eduardo-rocha)]

- Added patch to fix this bug in class Command.cs.

[Stephen Brandt (ztefn)]

Hi Eduardo,

Haguichi indeed uses a timeout for each command to prevent itself from waiting for eternity on a hanging command. This timeout is 60 seconds by default (you can change this setting in GConf).

If the command "hamachi list" takes more then 60 seconds to display on your system, then the timeout worked as intended. You could increase the timeout setting in GConf to a higher value. This should have the same result as your patch, but I still doubt it's a great use experience... having to wait for so long.

[Eduardo rocha (joao-eduardo-rocha)]

Hi Stephen,

I think I have not made myself very clear before. This issue is not related with "how long" a "hamachi list" takes, but with "how much data" it returns (well, raising the Timeout setting hasn't made a difference).

In my case, a "hamachi list" takes about 300ms to execute (measured with "time hamachi list") , but it returns more than 1200 lines, and the "Process.WaitForExit" seems to be not happy with this amount of data (maybe some buffer size issue in Mono?).

I'm not a C# programmer, but in Java I would solve this issue using an BufferedReader to read chunks of data from the process output. Sorry to say that all was I able to do in C# was replace the line that reads everything:
  > p.StandardOutput.ReadToEnd();
with a loop to read each line at a time:
  > while (!p.StandardOutput.EndOfStream) {
  > string line = p.StandardOutput.ReadLine();
  > output += line + "\n" ;
  > }

Best regards,

PS: Thanks for creating Haguichi! It's pretty useful overall!

[Stephen Brandt (ztefn)]

Ah, okay, it's very clear now! :)

A quick google search for "StandardOutput.ReadToEnd hangs" shows we're not the first one to hit this problem. I'll try to pick the best solution to fix this!

[Stephen Brandt (ztefn)]

Hi Eduardo,

I've just commited a fix: http://bazaar.launchpad.net/~ztefn/haguichi/trunk/revision/349

Because I wanted to keep the timeout limit for all executed commands, after a lot of experimenting the only working solution I found was the one described here: http://stackoverflow.com/questions/7960146/deadlock-on-out-error-buffer

It would be great if you could test the code to confirm if this fixes your problem. Please let me know if you need some help to get it running.

[Eduardo rocha (joao-eduardo-rocha)]

Hi Stephen,

I've just applied your fix, and it seems to be working quite well! =)

I'll be testing it over the next days, and let you know if I find something odd.

And thanks for your quick and hard work!