[openrtm-users 00987] Re: [1.0.0-RC1] データ送信中に接続線をdeleteするとRTCが死んでしまう

2009年 11月 2日 (月) 17:32:52 JST

安藤様

産総研の中島です。

パッチ提供ありがとうございます。
確認作業を行っているところ、
前回提供したサンプルで行った確認作業と
同一の事を何度か行っておりますが、
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 <y.nakajima ＠ aist.go.jp>:
> > 産総研の中島です。
> >
> > 追記です。
> >
> > 前メールで添付したサンプルを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が死んでしまい、全体として機能しな
> >> くなる場合がありうる状態です。
> >>
> >> 対応の方、よろしくお願いいたします。
> >>
> >> -----------------------------------------------------
> >> 〒305-8568
> >> 茨城県つくば市梅園1-1-1　つくば中央第2  本部情報棟 3204室
> >> 独立行政法人　産業技術総合研究所
> >> 知能システム研究部門　ヒューマノイド研究グループ
> >>
> >> 中島　裕介　(Yusuke Nakajima)
> >>
> >> TEL: 029-861-5080(内線55267)
> >> mailto: y.nakajima ＠ aist.go.jp
> >> -----------------------------------------------------
> >
> >
> >
> >
> 
> 
> 
> -- 
> 安藤慶昭＠独立行政法人産業技術総合研究所 知能システム研究部門
>     統合知能研究グループ 主任研究員, 博士(工学)
>     〒305-8568 つくば市梅園1-1-1 中央第2
>     e-mail: n-ando ＠ aist.go.jp, web: http://staff.aist.go.jp/n-ando
>     OpenRTM-aist: http://www.openrtm.org
> 
> Noriaki Ando, Ph.D.
>     Senior Research Scientist, RT-Synthesis R.G., ISRI, AIST
>     AIST Tsukuba Central 2, Tsukuba, Ibaraki 305-8568 JAPAN
>     e-mail: n-ando ＠ aist.go.jp, web: http://staff.aist.go.jp/n-ando
>     OpenRTM-aist: http://www.openrtm.org