[omniORB] Sun solaris crash

[Duncan Grisby]

On Friday 8 December, "Aeilt Zemering" wrote:

> I am having a problem with a C++ server with embedded python. It
> crashes with either a segmentation violation or a bus error.
>
> I am using omniORB3.02 and omniORBPython1.2 on Sun Solaris 2.5

What are you doing at the time of the crash?  Combined C++/Python
programs work OK for me, but I've only tried relatively simple tests.

It looks like it's crashing as it tries to create a Python object
reference in string_to_object.

I'm not sure I believe your stack trace:

> Current function is omniAnonObjRef::~omniAnonObjRef (optimized)
>    66   omniAnonObjRef::~omniAnonObjRef() {}
> (dbx)   [1] _lwp_kill(0x0, 0xb, 0x0, 0x13d407, 0x0, 0x13d405), at 0xef17898c
>   [2] __libthread_segvhdlr(0xb, 0xefffd848, 0xefffd688, 0xefffd5c8,
> 0x13d410, 0x
> 13d440), at 0xef2232fc
>   ---- called from signal handler with signal 11 (SIGSEGV) ------
>   [3] MT::LockImpl::lock(), at 0xef491f9c
>   [4] CORBA::Object::~Object(0x32c560, 0x0, 0x32c53c, 0xee7ed324,
> 0xefffd8e8, 0x
> ef1d3848), at 0xef41f878
> =>[5] omniAnonObjRef::~omniAnonObjRef(this = ???, delete = ???) (optimized),
> at
> 0xee794d80 (line ~66) in "anonObject.cc"

The ~omniAnonObjRef() call is meant to happen, followed by ~Object(),
but what is the MT::LockImpl::lock() thing?  That's nothing to do with
omniORB, so I presume it's part of your program. How the debugger came
to think ~Object() called it, I don't know.

I suggest you build omniORB and omniORBpy with debugging enabled, then
run your program inside dbx, rather than looking at a core file.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --