-
Notifications
You must be signed in to change notification settings - Fork 58
20160526のビルドでBodyRTCの読み込みで落ちる #104
Comments
見たところOutPortのコンストラクタあたりで落ちているようなのですが、OpenRTMのshared libraryとOutPort.hを実体化している部分(shared library?実行ファイル?)で、バージョンが違うということはないでしょうか? ros-indigo-openrtm-aist のOpenRTMのバージョン(リビジョン?)はいくつですか? |
ros-indigo-openrtm-aistのバージョンは1.1.0相当で1年以上更新されていません。 |
openrtm-aistをうちのPPAから入れられているということですね。 |
そうすると、先日rtm.pyのreadDataPort用に修正した以下の変更が悪さをしているんでしょうかね。
|
あれ、これってtrunkだけじゃなくてRELENG_1_1にも入ってるんですか? |
入ってます。本来ならヘッダの修正はマイナーリビジョンには入れないのですが、OutPort.hはクラステンプレートかつfinalなクラスという想定なので、入れてしまっております。rtm.pyのreadDataPortで落ちる件もありましたし。影響のある部分とかありますでしょうか? |
いえ、RELENG_1_1の方に入っていないと思っていたので、rtm.pyの修正をしていなかったのですが、こちらにも入ったのであればrtm.pyの修正も取り込ませていただきます。 |
でも、Choreonoidに影響があるのであれば、戻したほうがいいのかも。。。 ちなみに、OutPort.hを元に戻したらChoreonoidが落ちる問題は治りませんか? |
全く理由がわかりませんが、治りますね。 2016年5月27日 19:07 Noriaki Ando notifications@github.com:
|
同一プロセス内に存在する、libRTCに関係するバイナリはすべて新しいソースからビルドされたものですか?古いOpenRTMとリンクしているshared objectとかは混ざってませんか? |
システム内にlibRTC*.soが1つしかないことを確認しました。不思議ですね。 |
OutPort.hのコンストラクタの、
を
にするとどうなりますでしょうか? |
動きますね。 |
m_valueを0にすると動くのがよくわからないのですが、どういうことなんでしょうか? |
上のbacktraceを見ると、CORBAのsequenceのコピーコンストラクタのインデックスでアクセスしている部分で落ちているようなのですが、 ここはこの時点ではsequenceのサイズはまだ0のはずで、そもそもこのforループに入らないはずです。 ちなみに、手元でこの状況を再現するにはどうすればよろしいですか? |
メモリ破壊だとすると環境によって現象の出方が異なるかもしれませんが、僕の手元の環境では、ChoreonnoidをBUILD_OPENRTM_SAMPLESをONにしてコンパイルして、share/choreonoid-1.5/project/OpenRTM-PA10Pickup.cnoidを開くと問題の箇所で落ちますね。 |
ありがとうございます。こちらでも同じような現象を再現できました。
以下のように OpenRTM-PA10Pickup.cnoid をロードすると落ちました。
|
原因が分かりました。おそらくメンバーの初期化順の問題です。
コンストラクタでは、
その際、シーケンス内部の変数も不定のため、コピーコンストラクタでおかしなインデックスの領域を呼び出してしまっているようです。 本来であれば、
とするか、コンストラクタで、valuesのコンストラクタを明示的に呼び出してあげる必要があります。
ただ、後者の方法はコンパイラがWarningを出しますが。。。。いずれの方法も試しましたが、choreonoidは落ちなくなりました。 なお、 |
@n-andoさん、@fkanehiroさん |
はい、そのはずです。PR #105 を投げました。 |
ありがとうございます。 |
fix declaration order of member variables (ref #104)
@YoheiKakiuchi さん openrtm-aistは1.1.2+20160527+1729+12
で落ちるきがします。 |
さきほどchoreonoidが更新されて、20160602で修正されたものになっているようです。 |
@n-ando さん、コメントありがとうございました。教えて頂いた方法で、VirtualRobotRTCを生成する時にコケる、ということはなくなったのですが、その後でpythonからコンポーネントをロードして生成して、即座にポートのプロファイルを取ろうとすると、
といったエラーが起きます。 |
問題の範囲が少し絞れてきました。 |
write()されるとプロファイルが取れるようになるので、スタブが見えてないとかそういうことではなさそう。 |
https://github.com/s-nakaoka/choreonoid/blob/master/src/OpenRTMPlugin/VirtualRobotPortHandler.cpp#L379 |
enumを含んだデータ型のデータポートのプロファイルを取得する前には、enumのフィールドを初期化した上で、write()を一度呼んでおく必要がある。 |
@YoheiKakiuchi さん choreonoidがdebで1.5.0+dfsg+20160602+599+17~ubuntu12.04.1です。 |
@YoheiKakiuchi さん gdbかけてみた結果をお送りします。
|
データの初期化の問題は、
にしておけば、とりあえず未初期化のデータは来なくなるのでエラーは避けられそうですがどうでしょう。 あと、画像のような大きいデータがPortProfileに入っているのは問題ですね。将来的には、データをプロファイルからとるかどうかはオプションで選択できるようにしようと思っているのですが。 やはり、ワンショットでデータを取得する別の方法を考えたほうがいいのかな。 それよりも、readDataPort 等のグローバルな関数は、rtm.pyのRTcomponentのメンバー関数にできないもんでしょうか?そうすれば、頻繁にconnectすることなくいつでもデータを取ることができると思うのですが。 |
@n-ando さん、Pull型の通信について教えて頂けないでしょうか。 |
(こちらの手元の状況ですが)
のように過去のものに戻したら動いているようです。 |
@n-ando さん、addPropertyの値を0にすると問題なさそうです。 |
Pull型の接続ですが、以下のような構造になっています。
バッファはOutPortのconnector側にあります。
ご推察のとおりPull型ではInPort側が明示的に読みに行くのでpublisherは有りません。onExecute() が Pull connectorのバッファにひたすら書き込みに行くだけです。 addProperty の第2引数を 0 にするのはbranchに入れることが可能ですので、そのようにします。 |
launchpadでのビルドが以下のようなエラーで失敗しています。
|
上のコンパイルエラーですが32bitだけで起きるようです。 |
@n-ando さん、五月雨式で申し訳ありませんが、
といったエラーも起きます。 |
m_profileに排他制御しないといけないということでしょうか。 |
おそらくそうですね。>排他制御 |
こうですかね?>排他制御
|
はい、それで良さそうです。 |
@n-ando さん、排他制御の修正がtrunkにしか入っていないようなので、RELENG_1_1にも反映して頂けませんか? |
すみません、ROBOMECH参加中で作業が遅れました。現在RELENG_1_1にも修正がコミットされております。 |
debでインストールしている環境で、20160526のビルドにおいて、BodyRTCの読み込みでchoreonoidが落ちてしまいます。
あまり深入りできておりませんが、問題は最新のOpenRTMのソースにあるように思うのですが、現象が確認できるのがchoreonoidですので、こちらに報告させてもらいます。
20160526のopenrtm-aistを使って、ソースからコンパイルしても同じようになっております。
(ros-indigo-openrtm-aistをつかってコンパイルすると問題は起こりません)
最近の変更で何かありましたでしょうか? @n-ando
以下、Debugフラグをつけてコンパイルしたchoreonoidでのgdbの結果をお送りします。
The text was updated successfully, but these errors were encountered: