安藤様、

いただいたRingBuffer.hに置き換えて、問題のプログラムを1時間ほどテストして
いますが今のところ問題は再現していません。置き換える前は数分程度で
起きていたので直ったのではないかと思います。
ありがとうございました。

2010/6/18 Ando Noriaki :
> 金広さま、高瀬さま
>
> 安藤です
>
> コードをよく見てみたところ、2つのmutexが競合する部分がありました。
> これだとデッドロックする可能性があります。
> 添付のRingBuffer.hに置き換えて試してみていただけないでしょうか？
>
> 高瀬さん
> 詳細な情報＋分析ありがとうございました。
>
>
> 2010年6月18日15:24 Fumio Kanehiro :
>> 安藤様、
>>
>> 金広です。
>>
>> OpenRTM-aist-1.0.0-RELEASEを-gオプション付きでコンパイルして試した
>> ところスタックトレースは以下のようになりしたので、m_full.mutexのようです。
>> （行番号が少しずれていますが、これはRingBuffer.hのwrite()に対するr1971
>> の変更が関係あるかと思い、適用しているためです）
>>
>> 問題解決のヒントになるかも知れませんので現象が起きている環境を少し詳しく
>> 説明します。（前のメールとは若干変わっています）
>> 1つのrtcd上に生成された10程度のRTCが2つのECで駆動されています。
>> 2つのECはそれぞれ、200[Hz]、10[Hz]で動作しており、問題が起きているInPortは
>> 10[Hz]で駆動されるRTCのInPortで、そのInPortは200[Hz]で駆動されている
>> RTCのOutPortと接続されています。RingBufferの長さは1にしていて、ほぼ常に
>> フルの状態となっています。
>>
>> (gdb) bt
>> #0 0x00c0a422 in __kernel_vsyscall ()
>> #1 0x00cb4af9 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0
>> #2 0x00cb013b in _L_lock_748 () from /lib/tls/i686/cmov/libpthread.so.0
>> #3 0x00caff61 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0
>> #4 0x005e522f in coil::Mutex::lock (this=0xb4e0b530, value=..., sec=-1,
>> nsec=-1) at ../../../src/lib/coil/include/coil/Mutex.h:42
>> #5 Guard (this=0xb4e0b530, value=..., sec=-1, nsec=-1)
>> at ../../../src/lib/coil/include/coil/Guard.h:33
>> #6 RTC::RingBuffer::read (this=0xb4e0b530, value=...,
>> sec=-1, nsec=-1) at ../../../src/lib/rtm/RingBuffer.h:764
>> #7 0x005acbc7 in RTC::InPortPushConnector::read (this=0xb4e7e580, data=...)
>> at InPortPushConnector.cpp:92
>> #8 0x00cda5fa in RTC::InPort::read() ()
>>
>>
>> 2010/6/18 Ando Noriaki :
>>> 金広さま
>>>
>>> 安藤です
>>>
>>> ご報告ありがとうございました。
>>> こちらでも調査してみたいと思います。
>>> ちなみに、RingBuffer::read() 内には m_empty.mutex と m_full.mutex
>>> がありますが、どちらで止まっているかお分かりになりますでしょうか？
>>>
>>>
>>> 2010年6月17日17:37 Fumio Kanehiro :
>>>> 金広＠産総研です。
>>>>
>>>> OpenRTM-1.0.0-RELEASE-C++をソースからコンパイルしてUbuntu10.04で使用しています。
>>>>
>>>> TimedDoubleSeq型のデータを入力するInPortに対してisNew()で読み出せるデータが
>>>> あることを確認した上でread()を呼び出しているにも関わらず、read()でブロックされ、返ってこなく
>>>> なる場合があるようです。
>>>> その状態でgdbからinterruptをかけ、backtraceすると以下のようにmutexが取得できずに止まっている
>>>> ようです。
>>>>
>>>> (gdb) bt
>>>> #0 0x00ce4422 in __kernel_vsyscall ()
>>>> #1 0x00986af9 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0
>>>> #2 0x0098213b in _L_lock_748 () from /lib/tls/i686/cmov/libpthread.so.0
>>>> #3 0x00981f61 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0
>>>> #4 0x0027f22f in
>>>> RTC::RingBuffer::read(cdrMemoryStream&, long, long)
>>>> () from /usr/local/lib/libRTC-1.0.0.so.0
>>>> #5 0x00246bc7 in RTC::InPortPushConnector::read(cdrMemoryStream&) ()
>>>> from /usr/local/lib/libRTC-1.0.0.so.0
>>>> #6 0x07811aaa in RTC::InPort::read() ()
>>>>
>>>> この現象が発生する時の状況ですが、rtcdに10種類ほどのモジュールをロードし、10個ほどのRTCを
>>>> 生成し、それらを異なる周期で動作する3つのExecutionContextで実行させた場合にランダムな
>>>> タイミングで生じています。ログレベルを変えたりすると現象が起きなくなったりするので、微妙な
>>>> タイミングによって生じる問題なのではないかと考えています。
>>>>
>>>> 現象を再現させられるミニマムセットを作るのが難しいのですが、類似した現象に対する修正が
>>>> 1.0.0-RELEASE以降にありましたでしょうか？
>>>> （ちなみにdebパッケージの1.0.0-2も試してみましたが同じ現象が起きました）
>>>>
>>>>
>>>