[omniORB] Crashing bug in omniidl2 generated code

[Duncan Grisby]

On Wednesday 5 April, Nathaniel Smith wrote:

[...COPE sends an incorrect object reference to an omniORB server, and
the server crashes...]

> #4  0x40497f78 in __terminate () at visual.c:275
> #5  0x40498edd in terminate () at visual.c:275
> #6  0x406053f6 in CORBA::UnMarshalObjRef () at visual.c:275
> #7  0x4014ee2b in Controller_Helper::unmarshalObjRef () at visual.c:275
> #8  0x401b4e64 in _sk_DesktopKit::dispatch () at visual.c:275
> #9  0x405f5aaf in GIOP_S::HandleRequest () at visual.c:275
> #10 0x405f472f in GIOP_S::dispatcher () at visual.c:275

> Which implies that the crash is happening somewhere in
> CORBA::UnMarshelObjRef, called from
> Controller_helper::unmarshalObjRef, which is code generated by
> omniidl2.  Since it shouldn't be possible to crash the server from a
> client, it seems to me that the generated classes need to do more
> error checking of some sort.  I don't know if omniORB3 has this
> problem.

This is not a bug in omniORB, but your C++ compiler. As long as
omniORB has static knowledge of the types involved (which in your case
it does), it throws a CORBA::MARSHAL exception from below
unmarshalObjRef(). The exception should be caught by HandleRequest(),
but in your case it isn't. The call to terminate() is what happens on
Linux when an exception is not caught. This almost certainly means
that your gcc was not compiled with --enable-threads.

Cheers,

Duncan.

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