中島様

安藤です

ご報告ありがとうございます。
おそらくどこかでデッドロックを起こしているのだと思います。
あまり深く考えず、コネクタにアクセスするところを全部
ロックをかけてしまいましたので。。。

ただ、ご報告の現象からすると、タイミング依存で発生する
デッドロックのようなので、少々厄介な気がします。
調べるのは来週以降になりそうなので、少々お待ちいただけますか？
もし、どこのロックが関係しているかお分かりになりましたら、
教えていただければ幸いです。

2009年11月2日17:32 Yusuke Nakajima :
> 安藤様
>
> 産総研の中島です。
>
> パッチ提供ありがとうございます。
> 確認作業を行っているところ、
> 前回提供したサンプルで行った確認作業と
> 同一の事を何度か行っておりますが、
> OutPortを持つRTCが死んでしまう現象は、
> 今のところ発生しておりません。
>
> しかし、別の問題に遭遇しております。
> ２つのRTCを起動し、線を引いて、Activate後に
> 何度か、delete->再接続->delete->再接続を
> 繰り返していると、SystemEditor画面がフリーズ状態
> になり、線が残ったままSystemEditor上での操作を
> 受け付けなくなってしまいます。
>
> 数時間待っても戻ってこないので、eclipseごと終了し、
> RTCはctrl+zでkillしないとダメになります。
>
> ２つのRTCをローカル環境で起動すると発生頻度は低いのですが、
> ２台のPCに分散させ片方に飛ばすようにすると、割と高頻度で
> この状態になります。
>
> ちなみに、Ubuntu8.04環境で、前回スクリプトから、パッケージで
> インストールしていたのですが、今回、パッケージのRTM関連のみ
> 削除して、ソースを取得しパッチを当てたものをインストールした
> 環境での動作確認です。
>
> よろしくお願いいたします。
>
>
>> 皆さま
>>
>> 安藤です
>>
>> 1.0のデータポートの構造が変わったのが原因と思われます。
>> OutPort.hのOutPort::write() 関数内にて
>>
>> for (size_t i(0), len(conn_size); i < len; ++i)
>> {
>> ReturnCode ret;
>> ret = m_connectors[i]->write(m_cdr);
>> if (ret != PORT_OK)
>> {
>> result = false;
>> if (ret == CONNECTION_LOST)
>> {
>> disconnect(m_connectors[i]->id());
>> }
>> }
>> }
>>
>> なっていますが、m_connectors をロックするのをさぼっているため、
>> 書き込み中に m_connectors の要素が削除されて、segmentation fault
>> が発生しているものと思われます。
>>
>>
>> とりあえず、コネクタをmutexで保護するパッチを作成しました。
>> ざっと試したところ、OutPort側については落ちることはなさそうです。
>>
>> ただし、InPort側のRTCが落ちることがたまにありました。
>> InPortも同様にConnectorを持っているので、これと同じようにmutexで
>> 保護する必要があります。
>>
>> とりあえず、可能であればこのパッチを試してもらえませんか。
>> よろしくお願いいたします。
>>
>> InPort側のパッチについては、できたらMLで流します。
>>
>> 2009年10月30日14:43 Yusuke Nakajima :
>> > 産総研の中島です。
>> >
>> > 追記です。
>> >
>> > 前メールで添付したサンプルを0.4.2用に作成しなおし、
>> > OpenRTM0.4.2環境にて、1.0.0環境でテストしたのと同一の
>> > 無線LAN環境で、SystemEditorの線のdeleteのレスポンスが遅くなるくらいの
>> > 負荷をかけて数十回トライしましたが、同現象は起きませんでした。
>> >
>> > また、1.0.0のtimestamp用パッチ適用前の環境でもトライしましたが、
>> > こちらでは、同様の現象が再現されました。
>> >
>> >> 産総研の中島です。
>> >>
>> >> Ubuntu8.04環境にて、OpenRTM-aist-1.0.0-RC1 (C++)
>> >> とRtSystemEditor-1.0.0を使用しています。
>> >> （timestamp用のパッチ適用済みのもの）
>> >>
>> >> RtSystemEditor上で、OutPortを持つRTCとInPortを持つRTCを
>> >> 接続し、Activateさせ、データの送受信を行う単純なRTC群を
>> >> 用意し、Activate中に(Deactivateさせずに)、その接続線を
>> >> deleteすると、RTCが消えてしまい、（NameServer上ではゾンビ）
>> >> 以下のようなメッセージのいずれかを吐いて死んでいることがあります。
>> >> ちなみに、RTC自体は、onDeactivate()やonAbort()、onError()などには
>> >> 遷移せずに死んでいます。
>> >>
>> >> =====
>> >> [1]
>> >> "$ Segmentation Fault"
>> >>
>> >> [2]
>> >> "$ illegal error"
>> >>
>> >> [3]
>> >> "$ pure virtual method called terminate called without an active
>> >> exception
>> >> $ Aborted"
>> >> =====
>> >>
>> >> 上記３パターンのいずれかを出しますが、どれがどういう場合に
>> >> 出るのか、再現性が不明で把握しておりません。
>> >> （遭遇したのは上記３パターンのみですが、他もあるかもしれません。）
>> >>
>> >> また、この現象は必ず発生する訳ではなく、推測ですが、データ送信途中で
>> >> 線が切られると起こるように思えます。排他制御が効いていない？
>> >> 全体の負荷が軽いと起こらないようで、その場合は、１サイクル内でデータ送信
>> >> が早めに終了していて、その後に線をdeleteしているのかもしれません。
>> >>
>> >> 単純なサンプルを添付します。「testA」-->「testB」とDataPort接続し、
>> >> 「testA」側で毎onExecute()でデータを送信し、「testB」で受信したものを
>> >> 出力するのみです。
>> >>
>> >> これを、１台のPCでローカル環境で行っていると、なかなか症状が再現されない
>> >> のですが、２台のPCに分散させ、私の場合無線環境でNameServerに飛ばし、かつ、
>> >> rtc.conf内のrateを「1000000」くらいにし、極力、RTCの１サイクル中はデータ
>> >> 送信処理で負荷を占めるようにさせてトライしたところ、線をdeleteすると
>> >> 「testA」が死んでしまう現象が何度か再現できました。
>> >>
>> >> ということで、RTC群がActivateされている状態で、動的にPortの接続などを
>> >> 変更しようとすると、場合によってはRTCが死んでしまい、全体として機能しな
>> >> くなる場合がありうる状態です。
>> >>
>> >> 対応の方、よろしくお願いいたします。
>> >>