[omniORB] Crashing bug in omniidl2 generated code
Nathaniel Smith
njs@njs.dhis.net
Wed, 5 Apr 2000 04:29:15 -0700
Working on Berlin, we have various types and methods defined in idl;
in particular:
interface Graphic { ... };
interface LayoutKit {
...
Graphic hbox();
...
}
interface Controller : Graphic { ... };
interface DesktopKit {
...
Window shell(in Controller g);
...
};
I've also gotten COPE, a CORBA binding for perl, up and working and have
been using it to make Berlin clients. Perl is not a safe language, and
so when I accidentally did:
$hbox = $kits->{LayoutKit}->hbox();
$kits->{DesktopKit}->shell($hbox);
it ended up passing $hbox, a Graphic, to DesktopKit::shell, which was
expecting a Controller. At this point the server (not the client)
crashed.
Stefan suggested that this was because we were doing Controller::_narrow()
on the Graphic, which returned a null pointer (or the like) which wasn't
expected and crashed the server, but it turns out that even if we check
for CORBA::_is_nil and return, the server still crashes.
Investigating with gdb gives:
Program received signal SIGABRT, Aborted.
0x404f4911 in kill () at visual.c:275
275 }
(gdb) bt
#0 0x404f4911 in kill () at visual.c:275
#1 0x40468ee9 in pthread_kill () at visual.c:275
#2 0x40469365 in raise () at visual.c:275
#3 0x404f5c51 in abort () at visual.c:275
#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
#11 0x40614e7b in tcpSocketWorker::_realRun () at visual.c:275
#12 0x4062a8ce in omniORB::giopServerThreadWrapper::run () at visual.c:275
#13 0x40614de4 in tcpSocketWorker::run () at visual.c:275
#14 0x4065794f in omni_thread_wrapper () at visual.c:275
#15 0x40466c8f in pthread_start_thread () at visual.c:275
(gdb)
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.
-- Nathaniel