[openrtm-users 00864] Re: SdoConfiguration のデストラクタ

2009年 7月 9日 (木) 09:17:08 JST

小田桐さま

安藤です

お返事が遅くなり申し訳ありません。
また詳細な調査ありがとうございます。
こちらでも_var型_ptr型の扱いに関しては1.0開発時に詳細に調査し、
リークがないように修正いたしました。故あってRC1には反映させませんでしたが、
次（RC2？）では修正されたコードに置き換わる予定です。

後半の、on_shutdownとon_finalizeの呼び出し順、on_deactivateが
呼ばれない問題などについては調査して修正したいと思います。

ありがとうございました。

2009/06/16 17:35 に Yasuaki Odagiri<odagiri ＠ sec.co.jp> さんは書きました:
> 安藤様
>
> お世話になっております。
> セック 小田桐です。
>
> Configuration_implのデストラクタについてですが、コードを
> 見てみたところ、RTObject_implクラスのデストラクタで
> メンバ変数m_pSdoConfigImplのdeleteを行っていないため、
> 現状のコードでは、Configuration_implのデストラクタが
> 呼ばれないと思います。
>
> また、m_pSdoConfigImplをdeleteすると、別の問題も発生します。
> RTObject_implはコンストラクタでConfiguration_var型である
> メンバ変数にオブジェクトリファレンスを代入しています。
>
>    m_pSdoConfig = m_pSdoConfigImpl->getObjRef();
>
> Configuration_impl::getObjRef()は、Configuration_implが持つ
> Configuration_varを_ptr型としてそのまま返しているだけですので、
> オブジェクトリファレンスの参照回数がインクリメントされずに
> m_pSdoConfigに代入されています。
> そのため、RTObject_implのインスタンスを破棄した際、Configurationの
> 参照回数が余計にデクリメントされてしまいます。
> m_pSdoConfigに代入する際はduplicateする必要があるかと思います。
>
>
> ついでで恐縮ですが、その他、RTObject_implクラスで
> 気になった点も以下に報告しておきます。
>
> ・RTObject_implのコンストラクタでメンバ変数m_portAdminを
>  初期化する際、引数で渡しているORBとPOAの
>  オブジェクトリファレンスをduplicateしていません。
>  PortAdminクラスは受け取ったORBとPOAをそのまま_var型に
>  格納していますので、PortAdminのインスタンスが破棄されるとき、
>  ORBとPOAの参照回数が余計にデクリメントされてしまいます。
>  RTObject_implがORBとPOAをduplicateしてから渡す、もしくは、
>  PortAdminクラスでORBとPOAをduplicateする必要があるかと思います。
>
> ・RTObject_implのコンストラクタで_ptr型のメンバ変数m_objrefに
>  _this()でオブジェクトリファレンスを代入しています。
>  _this()でもらったオブジェクトリファレンスはCORBA::releaseで
>  解放する必要があると思いますので、m_objrefは_var型にすべきかと
>  思います。
>
> ・RTObject_impl::initialize内の以下のコードに問題があります。
>  RTObject.cppの317行目～
>
>    m_eclist.push_back(ec);
>    ExecutionContextService_var ecv;
>    ecv = ec->getObjRef();
>    if (CORBA::is_nil(ecv)) return RTC::RTC_ERROR;
>
>  PeriodicExecutionContext::getObjRefは、内部で保持している_var型の
>  オブジェクトリファレンスを_ptr型としてそのまま返しています。
>  そのため、ec->getObjRef()で取得したオブジェクトリファレンスは
>  duplicateするか、_var型ではなく_ptr型に入れるべきだと思います。
>  ここで_varに入れているため、スコープを抜けたときに余計に
>  参照回数がデクリメントされています。
>  そのため、ExecutionContextServiceのオブジェクトリファレンスを
>  最後まで保持しているm_ecMineがRTObject_implのデストラクタで
>  破棄されたときに問題が発生します。
>
> ・RTCを終了(exit)する際、on_shutdownがon_finalizeの後に
>  呼ばれます。
>  on_shutdownはon_finalizeの前に呼ばれるべきですが、
>  順番が逆になっています。
>  原因は、RTObject_impl::exit内で、m_ecMine[ic]->stop()と
>  m_ecOther[ic]->stop()がコメントアウトされているためです。
>  現状では、ECのstopは、on_finalizeの後に呼び出される
>  RTObject_impl::finalizePorts()内で行われています。
>
> ・RTCがActive状態で終了(exit)すると、on_deactivateが
>  呼ばれない場合があります。
>  特に、周期の遅いRTCではほぼ確実に発生します。
>  原因は、RTObject_impl::exit内で、deactivate_componentを
>  呼び出した後、実際にRTCがInactive状態に遷移するのを
>  待っていないためです。
>  PeriodicExecutionContextのactivate_componentや
>  deactivate_componentは、状態遷移のトリガーだけかけて、
>  実際の状態遷移は周期実行されているスレッド上で行うという
>  実装になっています。
>  そのため、周期が遅い場合、deactivate_component呼び出し後、
>  実際にInactive状態に遷移するまで時間がかかります。
>  RTObject_impl::exitは、deactivate_component呼出し後、
>  実際にInactive状態に遷移するのを待つべきではないかと
>  思います。
>
> 長文失礼いたしました。
>
> 以上、よろしくお願いいたします。
>
>
> On Thu, 4 Jun 2009 10:44:35 +0900
> Ando Noriaki <n-ando ＠ aist.go.jp> wrote:
>
>> 清水様
>>
>> 安藤です
>>
>>
>> > Configurationクラスは外部にexportして、
>> > ユーザが自由に使ってもよいものではないのでしょうか。
>> > もし、RTMの内部利用のみなら上記のような制約でも
>> > 問題ないと思いますが、外部exportしていて、
>> > ユーザにどう利用されるか分からないと仮定すると、
>> > 「deleteする前に必ずdefaultPOAでdeactivate
>> > しなければならない」という制約での
>> > 実装は危険だと感じます。
>>
>> SdoCondigurationクラスは、ConfigAdminクラスと一緒に使うように
>> できているので、その辺を了解しているひとなら使えると思いますが、
>> 今のところ他のユーザがそれらを単独で使うようには考慮していません。
>>
>> Configurationは
>> ・コンポーネント作成者からはあくまで、単なる変数へのアクセス
>> ・外部からはSDOPackage::Configurationインターフェースからのアクセス
>> （しかも、SDOが保持しているという前提）
>> という前提になっています。
>>
>> > デストラクタの実装は私も非常に気を使うのですが、
>> > このクラスの場合、defaultPOAでdeactivateさえ
>> > しておけば、deleteされても問題ないと思います。
>> > もし、deleteされる前にdeactivateされていた
>> > 場合でも問題ないように、
>> > deactivateの一連の処理をtry catch節で括っています。
>> > CORBA仕様では、deactivate済みのオブジェクトのservant_to_id()
>> > は例外を投げることになっているので、
>> > そうしておけば常に安全にdeactivateされると
>> > 考えたからです。
>> >
>> >
>> >> そうですね、RTObjectのshutdown内でのdeactivateでManager
>> > から
>> >> もらったPOAでdeactivateをしているのでこれは問題になる
>> > かもしれません。
>> >>
>> >> ところで、defaultでないPOAを使いたい場面とか、なにかあ
>> > りますか。
>> >> あるようなら、独自のServantBaseを実装してもよいのです
>> > が。。。
>> >
>> > 現在のところは必要ありませんが、将来の拡張性や
>> > メンテナンス性を考えての意見です。
>> > 万一、ManagerのPOAがデフォルトでなくなった場合でも、
>> > RTMのソース全体を見渡してPOAを逐一変更しなければ
>> > ならないとなるとデバッグも大変なので、
>> > そういう場合に備えてはどうでしょうか、ということです。
>>
>> doilでは、いずれこの辺のコードはなくなってしまうか、自動生成する
>> ともりだったので、汚いけど放置してました。
>> どうするか今後検討させていただきます。
>> --
>> 安藤慶昭＠独立行政法人産業技術総合研究所 研究員
>>                   知能システム研究部門 統合知能研究グループ
>>                   〒305-8568 茨城県つくば市梅園1-1-1 中央第2
>>                   TEL: 029-861-5981 FAX: 029-862-6631
>>                   n-ando ＠ aist.go.jp, n-ando ＠ ieee.org
>>
>
> -----------------------------------------------------------
>  株式会社セック 開発本部 第一開発部
>   〒150-0031 東京都渋谷区桜丘町 22-14 NESビル
>   TEL: 03-5458-7741    FAX : 03-5458-7726
>   URL: http://www.sec.co.jp
>
>  小田桐 康暁 (Yasuaki ODAGIRI)
>   E-Mail: odagiri ＠ sec.co.jp
> -----------------------------------------------------------
>
>
>


-- 
安藤慶昭＠独立行政法人産業技術総合研究所 研究員
                  知能システム研究部門 統合知能研究グループ
                  〒305-8568 茨城県つくば市梅園1-1-1 中央第2
                  TEL: 029-861-5981 FAX: 029-862-6631
                  n-ando ＠ aist.go.jp, n-ando ＠ ieee.org