既知問題にヒットしている可能性があるので、下記アーカイブで再現するか 確認してもらえるでしょうか？ http://ttssh2.sourceforge.jp/snapshot/snapshot-20140713.zip
ありがとうございます。 試してみましたが、同じように止まります。（800MBのファイル） なお、OSはWindows2012、ダウンロード元はRHEL6です。
Puttyのpscp.exeではダウンロードできますので、空き容量が無い等ではないと思います。
確認どうもありがとうございます。 お手数ですが、teraterm.ini の LogLevel を 200 にして、再現させて、そのときに できる"TTSSH.LOG"を採取いただけるでしょうか？
Windows XP で再現しています。
ログは以下の行で終わっており、特に異常はないように見えます。
SSH2_MSG_CHANNEL_SUCCESS was received(nego_status 4).
当方の環境では、再現しませんでした。 テストファイル： 50MB or 80MB (Linux kernel tarball) OS: Windows8.1 サーバ: SourceForge.jp
どうやら受信中に VT ウィンドウを最小化すると再現率が高いようです。SCP ウィンドウを最小化しても再現しません。また、送信では VT ウィンドウを最小化しても再現しないようです。#32992 と同じ問題かもしれません。
テストファイル: linux-2.6.32.63.tar.xz, linux-3.15.6.tar.xz, FreeBSD-9.3-RELEASE-i386-disc1.iso
OS: Windows XP
サーバ: shell.sourceforge.jp
対処を行ってみたので、再現しなくなるか確認願います。
0729試してみましたが、やはり応答なしになります。 ログを添付します。
doda 自分のところでも再現しました。OSはWindows 7です。
ただしVirtualPC上のWindows XP(XPmode)では2GB程度受信しましたが再現しません。
ちょっと調べた感じだと、ssh.c:SSH2_scp_fromremote() の PostThreadMessage() が失敗し続けてループしているようです。
TO: 各位 修正版アーカイブを下記に置いたので、再現しなくなるか確認願います。 パッチは添付します。 http://ttssh2.sourceforge.jp/snapshot/snapshot-20140811_scpfix.zip
doda yutakapon への返信
修正版アーカイブを下記に置いたので、再現しなくなるか確認願います。
試してみましたが、まだ再現します。
パッチは添付します。
差分はcontext diffかunified diffでお願いします。
doda への返信
パッチは添付します。
差分はcontext diffかunified diffでお願いします。
遅くなりましたが、context diffを添付します。 単なるリトライオーバーでは回避にならないのかもしれません。
doda 条件として、通信速度が関係しているようです。 shell.osdn.net等の離れたサーバだと起こらない(起こりにくい?)ですが、1000Base-TなLAN上にあるサーバやVirtualBox上の仮想マシンが相手だと起き易いです。
VirtualBox上のFreeBSD相手で帯域制限をかけながら試したところ、以下のように通信速度が速い程すぐに現象が再現しました。
| 帯域制限 | 転送可否 | 転送可能量 |
| なし | × | 400KB～1MB |
| 500Mbps | × | 20MB |
| 400Mbps | × | 25MB～30MB |
| 300Mbps | × | 500MB～1GB |
| 280Mbps | ○ | 全て |
280Mbps以下まで落とすと試した環境では発生しなくなりました。どの程度まで大丈夫かはPCの性能に依存しそうです。
doda doda への返信
ちょっと調べた感じだと、ssh.c:SSH2_scp_fromremote() の PostThreadMessage() が失敗し続けてループしているようです。
この状況から思ったのですが、メッセージの処理が追いつかずメッセージキューが溢れている可能性はないでしょうか?
メッセージキューが溢れる → PostThreadMessage()が失敗する → ループを回して PostThreadMessage() を繰り返す → メッセージの処理が行われずデッドロックする
調査のほうどうもありがとうございます。
本日、改めてTera Term最先端(r6507)で再現試験をしましたが、LANのスループットが100Mbpsしか
ないためか、再現できませんでした。
スレッドキューの溢れに関して、スレッドのforループを遅く回るようにして、意図的にキューを詰まるようにも
してみましたが、再現できませんでした。スレッドキューは最大10000個で、ファイルサイズにもよりますが、
50MBだとエンキューの回数が4000未満なので、数十MBレベルではキューフルにはなさなさそうです。
スレッドがまったく動けていない状態になっている可能性もありますが、原因はよく分かりません。
PostThreadMessage() の無限リトライが悪さをしているように思うので、
無限リトライをしない実装に変えようかとも思い始めました。
いずれにしても、どうするか少し考えてみます。
Fedora24 on Hyper-V環境で、再現できたので調査しています。
現状分かったことは下記の通りです。どうもスレッドが動けていないように見えています。
・PostThreadMessage()が ERROR_NOT_ENOUGH_QUOTA(1816)を返し続けることにより、doループから抜けられていない。
・ssh_scp_receive_thread()は SendMessage 関数でブロックしているように見える。
ssh_scp_receive_thread()で、SendMessage系処理をすべて無効化してみたら、
問題が再現しなくなったので(正常にファイル受信できる)、どうやらスレッドキューを PeekMassage する
ことと、同スレッド上でのメッセージ送信が競合することで、何かデッドロックが発生しているように見え、
それによりスレッドがブロックしてしまっているように見えます。
doda 手元の環境ではまだハングアップします。また、転送速度が全体的に遅くなった感じがします。(数百kb/s程度)
また、大きいファイルをダウンロードしているとクラッシュする事があります。
ハングアップおよびクラッシュするときの、詳細なオペレーションについて教えてもらえるでしょうか？
手元の環境で再現試験をしてみたいと思います。
doda 普通に3GB程度のファイルをSCPで受信するだけです。
末尾に示す環境で、ハングアップおよびクラッシュ、性能低下は再現しませんでした。
r6528の修正では、Tera Term(TTSSH)本体で PostMessage するときの無限ループを
止めているので、当該箇所でハングアップすることはないと考えているのですが、
どのあたりの処理でハングアップしているか、何か手がかりはないでしょうか。
●再現試験環境 受信ファイルサイズ： 3GB サーバ： CentOS 6.8(64bit) クライアント： Windows7 Pro(32bit), MEM2GB 使用バージョン： Tera Term最先端(r6538), v4.92 受信スループット： 約11MB/sec
Tera Term 4.93での修正は不十分であるため、本チケットはオープンのままとし、マイルストーンを再設定しました。
doda 可能かどうか未確認の思い付きレベルですが、SSHポート転送でのバッファリング処理と同じように、ある程度データが溜まった場合は受信を一時的に止めるという事は出来ないでしょうか?
doda への返信
可能かどうか未確認の思い付きレベルですが、SSHポート転送でのバッファリング処理と同じように、ある程度データが溜まった場合は受信を一時的に止めるという事は出来ないでしょうか?
できそうな感じなので、ブランチ作って検証を進めます。
Tera Term
SCPである程度大きなファイル（条件不明ですが、数十MB～するような気がします）をReceiveすると、CPU100%で応答なしになります。 調査用に何が必要でしょうか。
原因
対策