I just upgraded to R15B01 and ssh started behaving poorly. The problem is a bad catch expression in ssh_connection_manager.erl line 269:<div><br></div><div>The code is..</div><div><br></div><div><div><span class="Apple-tab-span" style="white-space:pre"> </span>catch %line 269</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span> _:Reason -></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>{disconnect, Reason, {{replies, Replies}, Connection}} =</div><div>
<span class="Apple-tab-span" style="white-space:pre"> </span> ssh_connection:handle_msg(</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> #ssh_msg_disconnect{code = ?SSH_DISCONNECT_BY_APPLICATION,</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span> description = "Internal error",</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> language = "en"}, Connection0, undefined,</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span> Role),</div></div><div><br></div><div><br></div><div>The Reason in the catch clause binds to 'function_clause'</div><div>The Reason returned by handle_msg() in my case was {11,"Internal error"}</div>
<div>Changing the catch clause to below seems to fix thing for me.</div><div><br></div><div><div><span class="Apple-tab-span" style="white-space:pre"> </span> _:_Reason -></div><br class="Apple-interchange-newline">
</div><div><br></div><div><br></div><div>My use case is that I open an ssh connection and then sequentially create and close a number of channels. A new process is created for each channel, and the process exits as soon as the eof message is received, leaving a few additional messages like exit_status dangling. This evidently exercises the above catch clause and makes the whole connection crash. </div>
<div><br></div><div>Note that I am talking to a very slow SSH server. My program also retries the connection and channel commands forever; after a few minutes it gets lucky and finishes without crashing.</div><div><br></div>
<div>A work-around is to have the channel process wait for the close message before exiting. This is probably the polite thing to do anyway.
</div><div><br></div><div>I did not have these issues in R14B03.</div><div><br></div><div>Regards,</div><div>Dan.</div>