(0/0)00DetailsReplySCPである程度大きなファイル(条件不明ですが、数十MB~するような気がします)をReceiveすると、CPU100%で応答なしになります。調査用に何が必要でしょうか。原因SSHサーバから受信したファイルデータをリンクドリストにつなぎ、スレッドでリストの先頭からデータを取り出し、スレッド上でファイルに追記するという動きをしている。この時、リストのエントリ数に上限を設けていないため、受信スピードが速いと、リストが肥大化する。対策SCP受信にフロー制御を追加する。NoneCommentReplyありがとうございます。試してみましたが、同じように止まります。OSはWindows2012、ダウンロード元はRHEL6です。NoneCommentReplyPuttyのpscp.exeではダウンロードできますので、空き容量が無い等ではないと思います。(del#24082)CommentReply確認どうもありがとうございます。ログは以下の行で終わっており、特に異常はないように見えます。MeCommentReply当方の環境では、再現しませんでした。ウィンドウを最小化すると再現率が高いようです。ウィンドウを最小化しても再現しません。ウィンドウを最小化しても再現しないようです。同じ問題かもしれません。(del#24082)CommentReply対処を行ってみたので、再現しなくなるか確認願います。NoneCommentReply0729試してみましたが、やはり応答なしになります。dodaCommentReply自分のところでも再現しました。XP(XPmode)では2GB程度受信しましたが再現しません。失敗し続けてループしているようです。修正版アーカイブを下記に置いたので、再現しなくなるか確認願います。修正版アーカイブを下記に置いたので、再現しなくなるか確認願います。試してみましたが、まだ再現します。diffでお願いします。返信パッチは添付します。diffでお願いします。diffを添付します。単なるリトライオーバーでは回避にならないのかもしれません。dodaCommentReply条件として、通信速度が関係しているようです。shell.osdn.net等の離れたサーバだと起こらない(起こりにくい?)ですが、1000Base-TなLAN上にあるサーバやVirtualBox上の仮想マシンが相手だと起き易いです。VirtualBox上のFreeBSD相手で帯域制限をかけながら試したところ、以下のように通信速度が速い程すぐに現象が再現しました。全て280Mbps以下まで落とすと試した環境では発生しなくなりました。どの程度まで大丈夫かはPCの性能に依存しそうです。失敗し続けてループしているようです。(del#24082)CommentReply調査のほうどうもありがとうございます。Term最先端(r6507)で再現試験をしましたが、LANのスループットが100Mbpsしかないためか、再現できませんでした。スレッドキューの溢れに関して、スレッドのforループを遅く回るようにして、意図的にキューを詰まるようにもしてみましたが、再現できませんでした。スレッドキューは最大10000個で、ファイルサイズにもよりますが、50MBだとエンキューの回数が4000未満なので、数十MBレベルではキューフルにはなさなさそうです。スレッドがまったく動けていない状態になっている可能性もありますが、原因はよく分かりません。無限リトライをしない実装に変えようかとも思い始めました。いずれにしても、どうするか少し考えてみます。Hyper-V環境で、再現できたので調査しています。現状分かったことは下記の通りです。スレッドが動けていないように見えています。ERROR_NOT_ENOUGH_QUOTA(1816)を返し続けることにより、doループから抜けられていない。関数でブロックしているように見える。することと、同スレッド上でのメッセージ送信が競合することで、何かデッドロックが発生しているように見え、それによりスレッドがブロックしてしまっているように見えます。修正により再現しなくなることを確認しました。dodaCommentReply手元の環境ではまだハングアップします。転送速度が全体的に遅くなった感じがします。(数百kb/s程度)また、大きいファイルをダウンロードしているとクラッシュする事があります。(del#24082)CommentReplyハングアップおよびクラッシュするときの、詳細なオペレーションについて教えてもらえるでしょうか?手元の環境で再現試験をしてみたいと思います。dodaCommentReply普通に3GB程度のファイルをSCPで受信するだけです。(del#24082)CommentReply末尾に示す環境で、ハングアップおよびクラッシュ、性能低下は再現しませんでした。4.93での修正は不十分であるため、本チケットはオープンのままとし、マイルストーンを再設定しました。可能かどうか未確認の思い付きレベルですが、SSHポート転送でのバッファリング処理と同じように、ある程度データが溜まった場合は受信を一時的に止めるという事は出来ないでしょうか?できそうな感じなので、ブランチ作って検証を進めます。