omniORB refcount miscount - TANGO Controls

# 7 years ago
jan	Hi, At DESY we perform tests before switching from Tango 8 to 9. Running some automatize tests of python servers on (Py)Tango9 I get a strange error: `omniORB: Assertion failed. This indicates a bug in the application using omniORB, or maybe in omniORB itself. file: ../../../../../src/lib/omniORB/orbcore/SocketCollection.cc line: 1663 info: pd_refcount > 0 omniORB: AsyncInvoker: Warning: unexpected exception caught while executing a task.` It looks harmless, i.e. it did not crashed any of my tests, but this miscount of reference counter in the removeSocket() method `void SocketCollection::removeSocket(SocketHolder* s) { OMNIORB_ASSERT(s->pd_belong_to == this); int refcount = 0; // Initialise to stop over-enthusiastic compiler warnings { omni_tracedmutex_lock sync(pd_collection_lock); OMNIORB_ASSERT(pd_refcount > 0); refcount = –pd_refcount; *(s->pd_prev) = s->pd_next; if (s->pd_next) s->pd_next->pd_prev = s->pd_prev; s->pd_belong_to = 0; } if (refcount == 0) delete this; }` looks really suspicious. This error comes randomly after all my tests. I'm testing purely python servers on debian jessie with python-tango (9.2.0), tango (9.2.5a), libomniorb4-1 (4.1.6-2). I've never seen this error even with the same tests for tango 8. Therefore, I would like to ask if anyone has idea what is going on or what could be a problem? Bests, Jan

# 7 years ago

Hi,

At DESY we perform tests before switching from Tango 8 to 9.
Running some automatize tests of python servers on (Py)Tango9 I get a strange error:


omniORB: Assertion failed.  This indicates a bug in the application
using omniORB, or maybe in omniORB itself.
 file: ../../../../../src/lib/omniORB/orbcore/SocketCollection.cc
 line: 1663
 info: pd_refcount > 0
omniORB: AsyncInvoker: Warning: unexpected exception caught while executing a task.

It looks harmless, i.e. it did not crashed any of my tests, but this miscount of reference counter in the removeSocket() method


void
SocketCollection::removeSocket(SocketHolder* s)
{
  OMNIORB_ASSERT(s->pd_belong_to == this);

  int refcount = 0; // Initialise to stop over-enthusiastic compiler warnings
  {
    omni_tracedmutex_lock sync(pd_collection_lock);

    OMNIORB_ASSERT(pd_refcount > 0);
    refcount = –pd_refcount;

    *(s->pd_prev) = s->pd_next;

    if (s->pd_next)
      s->pd_next->pd_prev = s->pd_prev;

    s->pd_belong_to = 0;
  }
  if (refcount == 0) delete this;
}

looks really suspicious. This error comes randomly after all my tests.

I'm testing purely python servers on debian jessie with python-tango (9.2.0), tango (9.2.5a), libomniorb4-1 (4.1.6-2).
I've never seen this error even with the same tests for tango 8.

Therefore, I would like to ask if anyone has idea what is going on or what could be a problem?

Bests,
Jan

# 7 years ago
Reynald	Hi Jan, What I would suggest is to update your version of omniORB to version 4.2.1 and to apply the patch available on our patches web page: http://www.tango-controls.org/downloads/patches/ Kind regards Reynald Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 7 years ago
jan	Thanks Reynald. We will try it.

# 7 years ago
jan	Hi, as an update I would like to mention that one has to be careful in creating thread local DeviceProxy instances with omniORB 4.1. In this case we get `omniORB: Application check failed. This indicates a bug in the application using omniORB. See the comment in the source code for more info. file: ../../../../../src/lib/omniORB/orbcore/corbaOrb.cc line: 989 info: pd_destroyed omniORB: Application check failed. This indicates a bug in the application using omniORB. See the comment in the source code for more info. file: ../../../../../src/lib/omniORB/orbcore/corbaOrb.cc line: 990 info: pd_refCount == 0` The gdb points a problem in creating of DeviceProxy. Moving the DeviceProxy constructor to the main thread the problem disappears. We are using debian8 with tango9. Since jessie/stretch provides only omniORB 4.1 we haven't managed to check if the problem disappears for 4.2.1, yet. Bests, Jan

# 7 years ago

jan

Hi,

as an update I would like to mention that one has to be careful in creating thread local DeviceProxy instances with omniORB 4.1.

In this case we get

omniORB: Application check failed. This indicates a bug in the application
  using omniORB.  See the comment in the source code for more info.
  file: ../../../../../src/lib/omniORB/orbcore/corbaOrb.cc
  line: 989
  info: pd_destroyed
omniORB: Application check failed. This indicates a bug in the application
  using omniORB.  See the comment in the source code for more info.
  file: ../../../../../src/lib/omniORB/orbcore/corbaOrb.cc
  line: 990
  info: pd_refCount == 0

The gdb points a problem in creating of DeviceProxy.
Moving the DeviceProxy constructor to the main thread the problem disappears.

We are using debian8 with tango9. Since jessie/stretch provides only omniORB 4.1 we haven't managed to check if the problem disappears for 4.2.1, yet.

Bests,
Jan

# 6 years ago
picca	Just for info, https://tracker.debian.org/pkg/omniorb-dfsg the 4.2.2 version is available in the experimental repository of Debian. So if you want you can backport it for stretch and recompile also tango, pytango etc… in order to check that it works with this version of omniorb. Cheers Frederic