チケット #34056

SCPダウンロードすると応答なしになる

登録: 2014-07-18 19:23 最終更新: 2019-12-10 19:03

報告者:
(匿名)
担当者:
(未割り当て)
チケットの種類:
状況:
オープン
コンポーネント:
マイルストーン:
(未割り当て)
優先度:
5 - 中
重要度:
5 - 中
解決法:
なし
ファイル:
2
投票
点数: 0
No votes
0.0% (0/0)
0.0% (0/0)

詳細

SCPである程度大きなファイル(条件不明ですが、数十MB~するような気がします)をReceiveすると、CPU100%で応答なしになります。 調査用に何が必要でしょうか。

原因

  • SSHサーバから受信したファイルデータをリンクドリストにつなぎ、スレッドでリストの先頭からデータを取り出し、スレッド上でファイルに追記するという動きをしている。この時、リストのエントリ数に上限を設けていないため、受信スピードが速いと、リストが肥大化する。

対策

  • SCP受信にフロー制御を追加する。

チケットの履歴 (43 件中 3 件表示)

2014-07-18 19:23 更新者: None
  • 新しいチケット "SCPダウンロードすると応答なしになる" が作成されました
2014-07-19 00:10 更新者: (del#24082)
  • 担当者(未割り当て) から yutakapon に更新されました
  • マイルストーン(未割り当て) から Tera Term 4.84 (完了済み) に更新されました
コメント
既知問題にヒットしている可能性があるので、下記アーカイブで再現するか
確認してもらえるでしょうか?

http://ttssh2.sourceforge.jp/snapshot/snapshot-20140713.zip
2014-07-23 15:03 更新者: None
コメント

ありがとうございます。 試してみましたが、同じように止まります。(800MBのファイル) なお、OSはWindows2012、ダウンロード元はRHEL6です。

2014-07-23 15:26 更新者: None
コメント

Puttyのpscp.exeではダウンロードできますので、空き容量が無い等ではないと思います。

2014-07-25 00:44 更新者: (del#24082)
コメント
確認どうもありがとうございます。
お手数ですが、teraterm.ini の LogLevel を 200 にして、再現させて、そのときに
できる"TTSSH.LOG"を採取いただけるでしょうか?
2014-07-25 01:07 更新者: (del#1144)
  • コンポーネント(未割り当て) から TTSSH に更新されました
コメント

Windows XP で再現しています。

ログは以下の行で終わっており、特に異常はないように見えます。

SSH2_MSG_CHANNEL_SUCCESS was received(nego_status 4).
2014-07-27 22:20 更新者: (del#24082)
  • 解決法なし から 動いてるけど? に更新されました
コメント
当方の環境では、再現しませんでした。

テストファイル: 50MB or 80MB (Linux kernel tarball)
OS: Windows8.1
サーバ: SourceForge.jp
2014-07-27 23:00 更新者: (del#1144)
  • 解決法動いてるけど? から なし に更新されました
コメント

どうやら受信中に 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

2014-07-29 23:24 更新者: (del#24082)
コメント

対処を行ってみたので、再現しなくなるか確認願います。

http://ttssh2.sourceforge.jp/snapshot/snapshot-20140729.zip

2014-08-05 17:41 更新者: None
コメント

0729試してみましたが、やはり応答なしになります。 ログを添付します。

2014-08-05 20:31 更新者: doda
コメント

自分のところでも再現しました。OSはWindows 7です。

ただしVirtualPC上のWindows XP(XPmode)では2GB程度受信しましたが再現しません。

ちょっと調べた感じだと、ssh.c:SSH2_scp_fromremote() の PostThreadMessage() が失敗し続けてループしているようです。

2014-08-11 23:00 更新者: (del#24082)
コメント
TO: 各位

修正版アーカイブを下記に置いたので、再現しなくなるか確認願います。
パッチは添付します。

http://ttssh2.sourceforge.jp/snapshot/snapshot-20140811_scpfix.zip

2014-08-12 22:51 更新者: doda
コメント

yutakapon への返信

修正版アーカイブを下記に置いたので、再現しなくなるか確認願います。

試してみましたが、まだ再現します。

パッチは添付します。

差分はcontext diffかunified diffでお願いします。

2014-08-28 00:33 更新者: (del#24082)
コメント

doda への返信

パッチは添付します。

差分はcontext diffかunified diffでお願いします。

遅くなりましたが、context diffを添付します。 単なるリトライオーバーでは回避にならないのかもしれません。

2014-08-28 09:20 更新者: (del#1144)
2014-11-24 00:34 更新者: (del#1144)
2015-02-28 20:39 更新者: (del#24082)
2015-05-02 00:56 更新者: (del#24082)
2015-06-02 19:35 更新者: (del#24082)
2015-11-07 21:04 更新者: (del#24082)
  • 担当者yutakapon から (未割り当て) に更新されました
2016-10-05 16:51 更新者: doda
コメント

条件として、通信速度が関係しているようです。 shell.osdn.net等の離れたサーバだと起こらない(起こりにくい?)ですが、1000Base-TなLAN上にあるサーバやVirtualBox上の仮想マシンが相手だと起き易いです。

VirtualBox上のFreeBSD相手で帯域制限をかけながら試したところ、以下のように通信速度が速い程すぐに現象が再現しました。

帯域制限 転送可否 転送可能量
なし × 400KB~1MB
500Mbps × 20MB
400Mbps × 25MB~30MB
300Mbps × 500MB~1GB
280Mbps 全て

280Mbps以下まで落とすと試した環境では発生しなくなりました。どの程度まで大丈夫かはPCの性能に依存しそうです。

2016-10-05 16:56 更新者: doda
コメント

doda への返信

ちょっと調べた感じだと、ssh.c:SSH2_scp_fromremote() の PostThreadMessage() が失敗し続けてループしているようです。

この状況から思ったのですが、メッセージの処理が追いつかずメッセージキューが溢れている可能性はないでしょうか?

メッセージキューが溢れる → PostThreadMessage()が失敗する → ループを回して PostThreadMessage() を繰り返す → メッセージの処理が行われずデッドロックする

2016-10-06 21:50 更新者: (del#24082)
コメント

調査のほうどうもありがとうございます。

本日、改めてTera Term最先端(r6507)で再現試験をしましたが、LANのスループットが100Mbpsしか
ないためか、再現できませんでした。

スレッドキューの溢れに関して、スレッドのforループを遅く回るようにして、意図的にキューを詰まるようにも
してみましたが、再現できませんでした。スレッドキューは最大10000個で、ファイルサイズにもよりますが、
50MBだとエンキューの回数が4000未満なので、数十MBレベルではキューフルにはなさなさそうです。
スレッドがまったく動けていない状態になっている可能性もありますが、原因はよく分かりません。

PostThreadMessage() の無限リトライが悪さをしているように思うので、
無限リトライをしない実装に変えようかとも思い始めました。
いずれにしても、どうするか少し考えてみます。

2016-10-06 21:51 更新者: (del#24082)
  • マイルストーン(未割り当て) から Tera Term 4.93 (完了済み) に更新されました
  • 担当者(未割り当て) から yutakapon に更新されました
2016-10-31 23:34 更新者: (del#24082)
コメント

Fedora24 on Hyper-V環境で、再現できたので調査しています。

現状分かったことは下記の通りです。どうもスレッドが動けていないように見えています。

・PostThreadMessage()が ERROR_NOT_ENOUGH_QUOTA(1816)を返し続けることにより、doループから抜けられていない。

・ssh_scp_receive_thread()は SendMessage 関数でブロックしているように見える。

2016-11-01 00:46 更新者: (del#24082)
コメント

ssh_scp_receive_thread()で、SendMessage系処理をすべて無効化してみたら、

問題が再現しなくなったので(正常にファイル受信できる)、どうやらスレッドキューを PeekMassage する

ことと、同スレッド上でのメッセージ送信が競合することで、何かデッドロックが発生しているように見え、

それによりスレッドがブロックしてしまっているように見えます。

2016-11-03 01:17 更新者: (del#24082)
  • 解決法なし から 修正済み に更新されました
コメント

r6528 で処置しました。

手元の環境(Fedora24 on Hyper-V)で、100%問題が発生していましたが、

修正により再現しなくなることを確認しました。

2016-11-21 18:23 更新者: doda
コメント

手元の環境ではまだハングアップします。また、転送速度が全体的に遅くなった感じがします。(数百kb/s程度)

また、大きいファイルをダウンロードしているとクラッシュする事があります。

2016-11-21 22:56 更新者: (del#24082)
コメント

ハングアップおよびクラッシュするときの、詳細なオペレーションについて教えてもらえるでしょうか?

手元の環境で再現試験をしてみたいと思います。

2016-11-22 10:35 更新者: doda
コメント

普通に3GB程度のファイルをSCPで受信するだけです。

2016-11-22 22:22 更新者: (del#24082)
コメント

末尾に示す環境で、ハングアップおよびクラッシュ、性能低下は再現しませんでした。

r6528の修正では、Tera Term(TTSSH)本体で PostMessage するときの無限ループを

止めているので、当該箇所でハングアップすることはないと考えているのですが、

どのあたりの処理でハングアップしているか、何か手がかりはないでしょうか。

●再現試験環境
受信ファイルサイズ: 3GB
サーバ: CentOS 6.8(64bit)
クライアント: Windows7 Pro(32bit), MEM2GB
使用バージョン: Tera Term最先端(r6538), v4.92
受信スループット:  約11MB/sec 
2016-11-30 21:47 更新者: (del#24082)
2016-11-30 21:48 更新者: (del#24082)
  • 解決法修正済み から なし に更新されました
コメント

Tera Term 4.93での修正は不十分であるため、本チケットはオープンのままとし、マイルストーンを再設定しました。

2017-02-28 21:33 更新者: (del#24082)
2017-05-27 01:11 更新者: (del#24082)
2019-08-06 22:14 更新者: doda
  • 詳細が更新されました
コメント

可能かどうか未確認の思い付きレベルですが、SSHポート転送でのバッファリング処理と同じように、ある程度データが溜まった場合は受信を一時的に止めるという事は出来ないでしょうか?

2019-08-12 20:31 更新者: (del#24082)
コメント

doda への返信

可能かどうか未確認の思い付きレベルですが、SSHポート転送でのバッファリング処理と同じように、ある程度データが溜まった場合は受信を一時的に止めるという事は出来ないでしょうか?

できそうな感じなので、ブランチ作って検証を進めます。

2019-08-23 19:21 更新者: (del#24082)
  • 詳細が更新されました
2019-08-31 00:51 更新者: (del#24082)
2019-10-16 21:15 更新者: (del#24082)
2019-12-10 19:03 更新者: (del#24082)
  • 担当者yutakapon から (未割り当て) に更新されました

添付ファイルリスト

編集

ログインしていません。ログインしていない状態では、コメントに記載者の記録が残りません。 » ログインする