コア: チケット
https://www.openrtm.org/redmine/
https://www.openrtm.org/redmine/redmine/favicon.ico
2013-08-27T01:26:41Z
Redmine for OpenRTM-aist
Redmine
バグ #2807 (新規): coil/Routing.cpp のwait(NULL)は不要
https://www.openrtm.org/redmine/issues/2807
2013-08-27T01:26:41Z
n-ando
Noriaki.Ando@gmail.com
<p>coil/Routing.cpp (posix版) 内で子プロセス終了を待つために wait(NULL) が数か所あるが、wait自体はpclose内に含まれているので不要</p>
<pre>
産総研の中岡です。
度々すみません、Mac OS X (Lion) においてマネージャ初期化時に固まるという
不可解な症状に遭遇しましたので、報告させてください。
状況としては、Choreonoidにおいて起動時にRTC::Manager::init()を行なってお
り、ある条件下でこの関数が固まります。
固まる箇所をたどっていくと、
Manager::initNaming() -
NamingManager::registerNameServer()-
NamingManager::createNamingObj() -
NamingOnCorba::NamingOnCorba() -
coil::dest_to_endpoint()
ときて、ここから呼ばれる
coil::find_dest_ifname() と
coil::ifname_to_ipaddr() の関数です。
1.1.0-RELEASEのsrc/lib/coil/posix/coil/Routing.cppにおいて、
108行と107行にある
wait(NULL)
でブロックしたまま帰ってきていません。
ある条件というのは、マネージャの初期化を行なっているプロセスから、
マネージャ初期化の前にネームサーバのコマンドを(別プロセスとして)起動し
ているということです。同じコマンドをあらかじめ他のプロセスから起動してあ
る場合は、問題なく動くのですが…。また、この症状が出るのはOS Xだけで、
WindowsやLinuxでは同じ事を行なっても問題なく動いています。
そして、OS Xでも上記の2つのwait(NULL)をどちらもコメントアウトすると、固
まらなくなり、その後も特に問題なく動いているように見えます。
ちなみにネームサーバのコマンドはomniNamesを参考に自前で実装した
Choreonoid付属のものです。WindowsやMacではネームサーバがデーモンとして自
動では起動しないのが普通だと思いますが、そのような場合でもChoreonoidを起
動するだけで簡単にシミュレーションを行えるように、この機能をつけています。
以上のような症状なのですが、今後のリリースで上記のwait(NULL)を除去しても
らうというのは問題ありますでしょうか?
</pre>
バグ #2802 (新規): rpi.shのgitがProxy環境下ではうまく動かない
https://www.openrtm.org/redmine/issues/2802
2013-08-14T09:09:31Z
n-ando
Noriaki.Ando@gmail.com
<p>(独)産業技術総合研究所<br />知能システム研究部門<br /> 安藤 慶昭 様</p>
<p>いつもお世話になっております。<br />ウィン電子工業の片見です。</p>
<p>PiRT-Unitを購入して頂いたお客様(首都大東京様)が<br />OpenRTM+PiRT-Unitでシステム構築をされています。</p>
<p>そのお客様は、<br />OpenRTMサイトを参考にされており、<br />セットアップスクリプト(rpi.sh)について<br />報告がありました。</p>
<p>rpi.sh の実行中に<br />git clone のエラーが発生したようです。<br />error: server certificate verification failed.</p>
<p>これは、校内のネットワーク環境(プロキシー)に依存して<br />発生するようです。<br />#弊社の環境では、<br />#再現しませんでした。</p>
<p>解決方法としては、<br />CA verificationを無効にすると<br />解決するとのことです。<br /> $sudo -s<br /> #git config --global --add http.sslVerify false</p>
<p><a class="external" href="http://psychomotorcycle.blogspot.jp/2011/07/proxygit-clone.html">http://psychomotorcycle.blogspot.jp/2011/07/proxygit-clone.html</a><br /><a class="external" href="http://codeblue.umich.edu/index/projects/codeblue/wiki/FAQ#The-requested-URL-returned-error-401-when-cloning-a-git-repository">http://codeblue.umich.edu/index/projects/codeblue/wiki/FAQ#The-requested-URL-returned-error-401-when-cloning-a-git-repository</a></p>
<p>お客様から、<br /> rpi.sh のバグではないのですが、<br /> さしつかえなければ、<br /> <a class="external" href="http://openrtm.org/openrtm/ja/content/system_setup_pirtunit">http://openrtm.org/openrtm/ja/content/system_setup_pirtunit</a><br /> に、対策を記載した方がよいのでは。<br />とお話しを頂きました。</p>
<p>注意書きのような形で<br />「error: server certificate verification failed.」が<br />発生した場合は、以下を実行してみてください。<br /> $sudo -s<br /> git config --global --add http.sslVerify false</p>
<p>弊社で再現しなかったので、<br />ちゃんと確認できたいのですが、<br />お時間あるときで結構ですので、<br />記載の検討をお願いいたします。</p>
<p>よろしくお願いいたします。</p>
バグ #2567 (新規): coilの.pcファイルが64bitの時機能しない
https://www.openrtm.org/redmine/issues/2567
2013-01-14T14:55:42Z
n-ando
Noriaki.Ando@gmail.com
<p>coilの.pcファイルが64bitの時機能しない</p>
バグ #2560 (新規): バッファやコネクタまわりに関しての改善・検討要望
https://www.openrtm.org/redmine/issues/2560
2013-01-07T01:20:35Z
n-ando
Noriaki.Ando@gmail.com
<p>静岡大の清水です。</p>
<p>バッファやコネクタまわりに関しての改善・検討要望です。<br />過日のSI2012で発表した、共有メモリベースの<br />データ通信機能を実装する際に問題となった点です。<br />ご検討頂ければ幸いです。</p>
<p>【問題点】<br />現行のコネクタの実装(InPortPushConnectorを例とします)では、<br />以下の手順で初期化(コンストラクタ内で)がされています。</p>
<p>(1) バッファ生成<br />(2) プロバイダの初期化(InPortProvider::init()のコール)</p>
<p>一般に、プロバイダ(コンシューマも)は特定のバッファとの組み合わせでしか<br />動作しない場合も考えられると思います。<br />すなわち、プロバイダがどのバッファを生成するかを制御できる必要があります。</p>
<p>どのバッファを生成するかは、ConnectorProfileにbuffer_typeを設定することで<br />制御できますが、もしユーザが間違ったbuffer_typeを指定した場合、<br />あるいは何も指定しなかった場合は、プロバイダに適合したバッファが生成されません。</p>
<p>【対応策】<br />この問題は、バッファの生成とプロバイダの初期化の順序を入れ替えることで<br />回避できます。私が実際に変更したコードは以下です。</p>
<p>・オリジナル(一部のみ抜粋)<br />InPortPushConnector(ConnectorInfo info, InPortProvider *provider)
{<br /> m_buffer = createBuffer(info);<br /> m_buffer->init(info.properties.getNode("buffer"));<br /> m_provider->init(info.properties);<br /> m_provider->setBuffer(m_buffer);<br /> m_provider->setListener(info, &m_listeners);<br />}</p>
<p>・変更後<br />InPortPushConnector(ConnectorInfo info, InPortProvider *provider)
{<br /> m_provider->init(info.properties); //<= バッファ生成前にプロバイダのinit()をする<br /> m_buffer = createBuffer(info);<br /> m_buffer->init(info.properties.getNode("buffer"));<br /> m_provider->setBuffer(m_buffer);<br /> m_provider->setListener(info, &m_listeners);<br />}</p>
<p>以上のように変更し、自作プロバイダのinit()内でbuffer_typeプロパティを<br />追加(または上書き)すれば、プロバイダがバッファの種類を完全に制御できます。</p>
<p>ところで、プロバイダのinit()の引数がconst指定になっていないのは、<br />プロバイダがConnectorProfileの情報(コピー)を書き変えても良いということだと、<br />私は判断しましたが、それで問題ないですよね。<br />もし書き換えを許可しないなら、const指定とする必要があります。</p>
<p>以上、よろしくご検討をお願いいたします。</p>
バグ #2543 (新規): InPortのバッファがring_bufferに固定になっているのでプロパティで与えられるようにする。
https://www.openrtm.org/redmine/issues/2543
2012-10-18T02:22:34Z
n-ando
Noriaki.Ando@gmail.com
<p>InPortのバッファがring_bufferに固定になっているのでプロパティで与えられるようにする。</p>
バグ #2488 (新規): configureの--with-libsオプションが機能しない
https://www.openrtm.org/redmine/issues/2488
2012-07-19T13:49:47Z
n-ando
Noriaki.Ando@gmail.com
<p>configureの--with-libsオプションを使用すると、空の-Lオプションが追加される。<br />例えば、--with--libs=-L=/usr/local/lib とすると、-L/usr/local/lib -L が設定される。</p>
バグ #2308 (新規): Windows版のconfig_rtc.hのバージョンが1.0.0のまま
https://www.openrtm.org/redmine/issues/2308
2011-12-22T08:22:36Z
n-ando
Noriaki.Ando@gmail.com
<p>Windows版のconfig_rtc.hのバージョンが1.0.0のまま。<br />自動生成するようにするか、直す。</p>
バグ #2158 (新規): RTCs can be deleted from a manager while participating in a Composition
https://www.openrtm.org/redmine/issues/2158
2011-06-07T13:20:57Z
gbiggs
geoffrey.biggs@aist.go.jp
<p>An RTC can be deleted from a manager while it is still participating in a Composite Component. This leads to the Composite Component having a dangling reference to the component.</p>
バグ #2084 (担当): 複合RTCのメンバ(子RTC)を削除すると,すべての子RTCがECからデタッチされてしまう
https://www.openrtm.org/redmine/issues/2084
2011-05-02T08:55:32Z
ta
tsakamoto@tech-arts.co.jp
<p>1.複合RTCをエディタで開いて子RTCを Delete<br />2.複合RTCは親RTCの ECに,子RTCがアタッチされる</p>
<p>子RTCの一部を削除すると,その子RTCだけがデタッチされるべきだと思うのですが,<br />すべての子RTCがデタッチされてしまうようです.</p>
バグ #1472 (新規): Compositeコンポーネントのポート公開に関する問題
https://www.openrtm.org/redmine/issues/1472
2010-05-12T09:54:19Z
kurihara
shinji0608@gmail.com
<p>RTSEにてCompositeコンポーネントを作成する場合に、”New Composite Component"ダイアログにて公開するポートを指定しても、composite.confに記述されたポートだけが公開ポートとなる。</p>
<p>Manager::createComponent()内の処理にて、このメソッドの引数で与えられたプロパティをマージしている処理があるが、引数で指定されたプロパティをマージした後に、component.confの内容をマージしているため、component.confで指定した値で上書きされてしまっている。</p>
<p>対策としては、configureComponent(comp, prop)の後で、compに対してcomp_propをsetProperties()でセットする事でcreateComponent()の引数で指定されたプロパティが有効となる。</p>
バグ #1430 (新規): Managerのshutdownに関する問題
https://www.openrtm.org/redmine/issues/1430
2010-04-22T09:39:38Z
n-ando
Noriaki.Ando@gmail.com
<ul>
<li>アプリケーション終了時にRTCのexit()およびcleanupComponents()を呼ばずにmanager->shutdown()を呼ぶ場合エラーなしで終了する。</li>
<li>マネージャのshutdown関数はexit()だけ呼んで、cleanupCOmponents()を呼ばないため、コンポーネントのデストラクタが呼ばれない</li>
<li>マネージャシャットダウンの前にexit()・cleanupComponents()を手動で呼ぶと落ちる</li>
</ul>
<p>ML01184から</p>
<p>1) Manager shutdown<br />When calling manager->shutdown() at the end of the main application without calling exit() on the component and cleanupComponents() on the manager the application exits without errors. However, the shutdown method of the manager only calls exit() on the components but never calls cleanupComponents() and hence the destructors of the components are never called. Maybe you can provide a fix here. Calling exit() and cleanupComponents() manually before manager->shutdown() results in a segmentation fault!!! Calling these methods from a gui component and not from main does not cause a segmentation fault.<br />Is this a known bug?</p>
バグ #1429 (新規): rtc-template で module を含むIDLを与えるとエラーになる
https://www.openrtm.org/redmine/issues/1429
2010-04-22T08:55:32Z
n-ando
Noriaki.Ando@gmail.com
<p>rtc-template で module を含むIDLを与えるとエラーになる<br />ML 00909にて指摘。</p>
<p>OpenRTM-aist開発者の皆様<br />九州工業大学 小田謙太郎と申します。</p>
<p>rtctemplate 0.4.2 において、moduleを含むIDLを入力とするとエラーが発生する問題について、報告いたします。</p>
<p>=== IDL ここから ====<br />module mymodule {<br /> interface MyService {<br /> };<br />};
=== IDL ここまで ====</p>
<p>この IDL を 以下のコマンドラインでrtctemplate(CUI Java版)を起動します。</p>
<p>=== コマンド ここから ====<br />java jp.go.aist.rtm.rtctemplate.CuiRtcTemplate<br />--output=. --backend=java --module-name=Hoge --module-desc=Foo<br />--module-vender=GaGa --module-category=Provider<br />--module-comp-type=DataFlowComponent --module-act-type=SPORADIC<br />--module-max-inst=1<br />--service="myservice:myservice0:mymoduel::MyService" <br />--service-idl=Module.idl
=== コマンド ここまで ====</p>
<p>クラスパスは、必要なものが通してあると仮定しています。<br />このコマンド結果が次に示します。</p>
<p>=== 結果 ここから ====<br />Invalidated argument for:[--service] args:[myservice, myservice0, mymoduel, , MyService]<br />Generate fail.
=== 結果 ここまで ====</p>
<p>このように、テンプレートの生成に失敗してしまいます。<br />これは、module の区切り文字である"::"がrtctemplate の区切り文字と<br />重複して扱われているのが原因ではないかと思います。</p>
<p>一方、Eclipse上で動作するGUI版のrtctemplate 0.4.2によるJavaテンプレート生成については、<br />この区切り文字のコンフリクトはおきませんが、生成されるコードに以下の記述が見られます。</p>
<p>mymodule::MyService</p>
<p>Java言語では::は機能しませんので、エラーが発生してしまいます。</p>
<p>mymodule.MyService</p>
<p>と生成されるべきかと思います。</p>
<p>以上エラーの報告でした。<br />ご対応検討いただければと思います。</p>
バグ #1427 (新規): InPort::getStatus() の追加
https://www.openrtm.org/redmine/issues/1427
2010-04-22T08:43:55Z
n-ando
Noriaki.Ando@gmail.com
<p>InPort::getStatus() の追加</p>
バグ #818 (担当): 複合RTCの公開Port設定について
https://www.openrtm.org/redmine/issues/818
2009-07-23T02:38:09Z
ta
tsakamoto@tech-arts.co.jp
<p>異なるパス上で動作するインスタンス名,Port名の同じRTCを複合化した場合,公開Portの設定ができない.</p>
<p>複合RTCの公開Portの設定は,PeriodicECSharedComposite内で行っているが,<br />addPortとremovePortにおいて,インスタンス名とポート名だけをみて検索を行っている.<br />このため,上記のような場合に公開Portの識別ができない.</p>
<p>検索条件にNameService上のフルパス情報,コンポーネントIDなどを追加する必要がある.</p>
バグ #817 (担当): Configurationの削除
https://www.openrtm.org/redmine/issues/817
2009-07-23T02:35:23Z
ta
tsakamoto@tech-arts.co.jp
<p>ConfigurationSetに一度項目を追加すると,削除ができない</p>
<p>Configuration_impl::set_configuration_set_values<br /> → ConfigAdmin::setConfigurationSetValues<br />内の処理において,設定されたConfigurationSetを反映させるために,<br /> p << config_set;<br />という処理を行っているが,この処理がプロパティ情報の「マージ処理」であるためconfig_set側で項目を削除していても,p側でその項目が削除されない.</p>
<p>Configurationの処理のみを考えると,ここではマージ処理ではなく,入れ替え処理が必要になると思う.<br />ただし,Defaultで設定されているConfigurationSetの情報を削除してしまうのは問題があるため,何らかの識別処理が必要と思われる.</p>