Tíquete #34056

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

: 2014-07-18 19:23 Última Atualização: 2019-12-10 19:03

Relator:
(Anônimo)
Dono:
(Nenhum)
Tipo:
Estado:
Aberto
Componente:
Marcos:
(Nenhum)
Prioridade:
5 - Medium
Gravidade:
5 - Medium
Resolução:
Nenhum
Arquivo:
2
Vote
Score: 0
No votes
0.0% (0/0)
0.0% (0/0)

Details

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

原因

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

対策

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

Ticket History (3/43 Histories)

2014-07-18 19:23 Updated by: None
  • New Ticket "SCPダウンロードすると応答なしになる" created
2014-07-19 00:10 Updated by: (del#24082)
Comentário
既知問題にヒットしている可能性があるので、下記アーカイブで再現するか
確認してもらえるでしょうか?

http://ttssh2.sourceforge.jp/snapshot/snapshot-20140713.zip
2014-07-23 15:03 Updated by: None
Comentário

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

2014-07-23 15:26 Updated by: None
Comentário

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

2014-07-25 00:44 Updated by: (del#24082)
Comentário
確認どうもありがとうございます。
お手数ですが、teraterm.ini の LogLevel を 200 にして、再現させて、そのときに
できる"TTSSH.LOG"を採取いただけるでしょうか?
2014-07-25 01:07 Updated by: (del#1144)
  • Componente Update from (Nenhum) to TTSSH
Comentário

Windows XP で再現しています。

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

SSH2_MSG_CHANNEL_SUCCESS was received(nego_status 4).
2014-07-27 22:20 Updated by: (del#24082)
  • Resolução Update from Nenhum to Works For Me
Comentário
当方の環境では、再現しませんでした。

テストファイル: 50MB or 80MB (Linux kernel tarball)
OS: Windows8.1
サーバ: SourceForge.jp
2014-07-27 23:00 Updated by: (del#1144)
  • Resolução Update from Works For Me to Nenhum
Comentário

どうやら受信中に 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 Updated by: (del#24082)
Comentário

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

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

2014-08-05 17:41 Updated by: None
Comentário

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

2014-08-05 20:31 Updated by: doda
Comentário

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

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

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

2014-08-11 23:00 Updated by: (del#24082)
Comentário
TO: 各位

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

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

2014-08-12 22:51 Updated by: doda
Comentário

yutakapon への返信

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

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

パッチは添付します。

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

2014-08-28 00:33 Updated by: (del#24082)
Comentário

doda への返信

パッチは添付します。

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

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

2014-08-28 09:20 Updated by: (del#1144)
2014-11-24 00:34 Updated by: (del#1144)
2015-02-28 20:39 Updated by: (del#24082)
2015-05-02 00:56 Updated by: (del#24082)
2015-06-02 19:35 Updated by: (del#24082)
2015-11-07 21:04 Updated by: (del#24082)
  • Dono Update from yutakapon to (Nenhum)
2016-10-05 16:51 Updated by: doda
Comentário

条件として、通信速度が関係しているようです。 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 Updated by: doda
Comentário

doda への返信

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

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

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

2016-10-06 21:50 Updated by: (del#24082)
Comentário

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

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

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

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

2016-10-06 21:51 Updated by: (del#24082)
2016-10-31 23:34 Updated by: (del#24082)
Comentário

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

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

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

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

2016-11-01 00:46 Updated by: (del#24082)
Comentário

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

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

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

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

2016-11-03 01:17 Updated by: (del#24082)
  • Resolução Update from Nenhum to Fixed
Comentário

r6528 で処置しました。

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

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

2016-11-21 18:23 Updated by: doda
Comentário

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

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

2016-11-21 22:56 Updated by: (del#24082)
Comentário

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

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

2016-11-22 10:35 Updated by: doda
Comentário

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

2016-11-22 22:22 Updated by: (del#24082)
Comentário

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

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 Updated by: (del#24082)
2016-11-30 21:48 Updated by: (del#24082)
  • Resolução Update from Fixed to Nenhum
Comentário

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

2017-02-28 21:33 Updated by: (del#24082)
2017-05-27 01:11 Updated by: (del#24082)
2019-08-06 22:14 Updated by: doda
  • Details Updated
Comentário

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

2019-08-12 20:31 Updated by: (del#24082)
Comentário

doda への返信

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

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

2019-08-23 19:21 Updated by: (del#24082)
  • Details Updated
2019-08-31 00:51 Updated by: (del#24082)
2019-10-16 21:15 Updated by: (del#24082)
2019-12-10 19:03 Updated by: (del#24082)
  • Dono Update from yutakapon to (Nenhum)

Attachment File List

Editar

You are not logged in. I you are not logged in, your comment will be treated as an anonymous post. » Login