• "logger.enable: NOとするとManagerのinitでフリーズする場合がある"
  • 症状
  • 調査結果
    • 問題となっていると思われる箇所

"logger.enable: NOとするとManagerのinitでフリーズする場合がある"

症状

rtc.confにて、"logger.enable: NO"を指定した場合、Manager::init(0,NULL)で処理が止まってしまう場合がある。
("logger.enable:"のデフォルト値はYESである)

調査結果

OpenRTMのソースにプリント文を追加し、プリントデバッグを行った結果、 NamingManagerクラスのregisterNameServer()などから呼ばれているSystemLoggerクラス内のRTC_TRACEやRTC_INFO等から呼ばれるbasic_logstream::level()の"return *this"で処理が止まっていた。

問題となっていると思われる箇所

• NamingManager.cppのコンストラクタにて、setLogLevel()やsetLogLock()が呼ばれている。 これは、Managerクラスでは、"logger.enable: NO"の場合、setLogLevel()は呼ばれないようになっているにも拘わらず、NamingManagerにてsetLogLevel()が無条件に呼ばれるため問題ではないかと思う。
  ここでも、Manager::initLogger()のようにmanager->getConfig()["logger.enable"]に"logger.enable"を取得し条件分岐する必要があるのでは?

• basic_logstreamクラス(SystemLogger.h)の__ostream_type& level(int level);メソッドにて、"logger.enable: NO"にも拘わらず、引数levelによっては*thisが返されてしまう。
  (デフォルトのログレベルがNORMALなため、RTC_INFOなどの時は*thisが返される。)
  ここは、m_DummyStreamが返されるべきでは?

上記の問題は、あるアプリケーションからRTミドルウェアを利用する際に発生した。
コンポーネントだけをコンソールから実行した場合は特にエラー等は発生しない。
ただ、コンポーネントをコンソールから実行した場合でも"logger.enable: NO"を 指定した場合、たまたまエラーが発生していないだけで、どこか意図していない領域を参照しているのではないかと思う。
また、今回の場合は、Manager::init()を呼びbasic_logstream::level()が返す"*this"が参照してはいけない領域を示しており、エラーになったのではないかと思っている。
実際に、basic_logstream::level()がm_DummyStreamを返す場合はエラーとならなかった。