Ticket #34056

Vote
Score: 0
No votes
0.0% (0/0)
0.0% (0/0)

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

Open Date: 2014-07-18 19:23 Last Update: 2017-05-27 01:11

Reporter: (Anonymous) Owner: yutakapon
Type: Bugs Status: Open [Owner assigned]
Component: TTSSH MileStone: (None)
Priority: 5 - Medium Severity: 5 - Medium
Resolution: None

Details

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

Attachment File List

Ticket History (3/37 Histories)

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

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

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

2014-07-23 15:26 Updated by: None
Comment

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

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

Windows XP で再現しています。

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

SSH2_MSG_CHANNEL_SUCCESS was received(nego_status 4).
2014-07-27 22:20 Updated by: yutakapon
  • Resolution Update from None to Works For Me
Comment
当方の環境では、再現しませんでした。

テストファイル: 50MB or 80MB (Linux kernel tarball)
OS: Windows8.1
サーバ: SourceForge.jp
2014-07-27 23:00 Updated by: maya
  • Resolution Update from Works For Me to None
Comment

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

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

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

2014-08-05 17:41 Updated by: None
Comment

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

2014-08-05 20:31 Updated by: doda
Comment

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

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

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

2014-08-11 23:00 Updated by: yutakapon
Comment
TO: 各位

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

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

2014-08-11 23:01 Updated by: yutakapon
  • File scpfix.diff (File ID: 5129) is attached
2014-08-12 22:51 Updated by: doda
Comment

yutakapon への返信

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

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

パッチは添付します。

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

2014-08-28 00:32 Updated by: yutakapon
  • File scpfix.diff (File ID: 5132) is attached
2014-08-28 00:33 Updated by: yutakapon
Comment

doda への返信

パッチは添付します。

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

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

2014-08-28 09:20 Updated by: maya
2014-11-24 00:34 Updated by: maya
2015-02-28 20:39 Updated by: yutakapon
2015-05-02 00:56 Updated by: yutakapon
2015-06-02 19:35 Updated by: yutakapon
2015-11-07 21:04 Updated by: yutakapon
  • Owner Update from yutakapon to (None)
2016-10-05 16:51 Updated by: doda
Comment

条件として、通信速度が関係しているようです。 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
Comment

doda への返信

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

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

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

2016-10-06 21:50 Updated by: yutakapon
Comment

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

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

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

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

2016-10-06 21:51 Updated by: yutakapon
2016-10-31 23:34 Updated by: yutakapon
Comment

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

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

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

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

2016-11-01 00:46 Updated by: yutakapon
Comment

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

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

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

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

2016-11-03 01:17 Updated by: yutakapon
  • Resolution Update from None to Fixed
Comment

r6528 で処置しました。

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

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

2016-11-21 18:23 Updated by: doda
Comment

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

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

2016-11-21 22:56 Updated by: yutakapon
Comment

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

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

2016-11-22 10:35 Updated by: doda
Comment

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

2016-11-22 22:22 Updated by: yutakapon
Comment

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

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: yutakapon
2016-11-30 21:48 Updated by: yutakapon
  • Resolution Update from Fixed to None
Comment

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

2017-02-28 21:33 Updated by: yutakapon
2017-05-27 01:11 Updated by: yutakapon

Edit

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