Project

General

Profile

バグ #1431

servant still activatedの問題

Added by n-ando almost 14 years ago. Updated almost 14 years ago.

Status:
終了
Priority:
通常
Assignee:
Target version:
-
Start date:
04/22/2010
Due date:
% Done:

100%

Estimated time:

Description

RTCのexit()/cleanupComponents() を呼ぶと、servant still activatedエラーが出る。
これは、プロバイダポートをコンポーネントに登録したときだけ出る。

ML01884より

2) Deletion of servants that are still activated
By calling exit() on a component and subsequent cleanupComponents() from a gui thread, we get the error:
omniORB: ERROR -- A servant has been deleted that is still activated.
id: root<6> (active)
omniORB: Assertion failed. This indicates a bug in the application
using omniORB, or maybe in omniORB itself.
file: ../../../../../src/lib/omniORB/orbcore/omniServant.cc
line: 222
info: activation_found

This error only occurs when we register a provider port in the component. When removing the provider port it works without problems. I should add that this problem only occurs for one of our components - however, we can not find any differences between the components and hence it is a riddle to us what causes this error. Maybe you can provide some ideas?

History

#1 Updated by n-ando almost 14 years ago

  • % Done changed from 0 to 10

おそらく、CorbaPort::CorbaProviderHolder において、サーバントは最終的にどこからもdeactivateされない。
少なくとも、CorbaProviderHolderのデストラクタでdeactivateすべき。

#2 Updated by n-ando almost 14 years ago

サービスプロバイダインターフェースを持つRTCをactive状態のままexit()すると、プロバイダがアクティブのままサーバントが削除されるため、このエラーが発生する。
原因の一つとして、CORBAポートとサーバントの宣言順序にある。宣言順序が
  • Port, Servantの順だとエラー
  • Servant, Portの順だとエラーは出ない
    のようになる。これは、オブジェクトの削除時にメンバーは(仕様で規定されているかどうかは分からないが、一般的には)宣言順と逆順で解体されるため、前者のように、Portがオブジェクトリファレンスを保持しているのに、先にServantが解体されるとORBの警告が出る。したがって、Portを先に解体し、リファレンスを解放してからServantを削除するのがより安全である。ただし、タイミングの問題もあるようで、前者の場合でも、ログメッセージを標準出力に出すなど、処理が重い場合ORBが気がつく前に両方とも削除されるためエラーが出ないケースもある。
解決方法として、
  • PortAdmin::finalizePorts において deactivatePorts() を呼び出しプロバイダをアクティブ化する
  • テンプレートが吐き出すコードにおいて、Servantの宣言を先にする
    の両方を行うべきである。

とりあえず、前項のみでエラーは出なくなる。また、第2項についてはC++の仕様を調べてみないとわからないが、宣言順序で落ちたり落ちなかったりするのはあまり良いロジックではない。

#3 Updated by n-ando almost 14 years ago

  • Status changed from 新規 to 終了
  • % Done changed from 10 to 100

Also available in: Atom PDF