[omniORB] deallocation of unmarshalled data...
james.eggleston@vega.de
james.eggleston@vega.de
Thu, 12 Jul 2001 11:18:58 +0100
Hi=2C
I am trying to implement a COM i=2Ff to an already existing CORBA i=2Ff=
=2E The
platform is Windows NT 4=2E0=2C SP5=2C running omniORB v3=2E0=2E3 talki=
ng to a server
machine using ORBIX v2=2E1=2E I am using Visual C++ to build my COM obj=
ects=2E It is
my first project using CORBA and I am more or less learning as I go=2E=2E=
=2E it has
been "so far=2C so good=22=2C up till now! I assume that I am doing som=
ething really
silly=2C so if there is an "obvious omission=22=2C then that is probabl=
y the problem!
Hope someone can help!
Thanks=2C
James=2E
I had been getting a problem with DEBUG assertions popping when objects=
are
going out of scope=2E=2E=2E=2E up to now the problem has always caused =
by my lack of
knowledge or inexperience with CORBA ( or stupidity :=29 ) i=2Ee=2E not=
using
=5FCORBA=5Fstring=5Fdup for assinging to string=5Fvar's etc=2E=2E=2E
However=2C I have now got a problem that I can't seem to get away from=2C=
and it
would *seem* that the problem is internal to omniORB=2E=2E=2E=2E=2E ( h=
opefully I am about
to highly embarrassed by being proved wrong! :=29 )=2E=20
It has come down to this basic situation=3A
I create a object to handle events from the server=2E This object's int=
erface is
derived from an base interface provided by the people who built the ser=
ver=2E I
have *EMPTY* overloaded methods in my derived class=2E i=2Ee=2E I do no=
processing of
the data passed to my 'event handler' method at all=2E=20
I register this object with the server=2C so that when a suitable event=
occurs=2C it
will notify my implementation=2E
Sure enough=2C after a small amount of time=2C a breakpoint on my (empt=
y=29 event
handling function is hit=2E Stepping through the code takes me back to =
the calling
method=2C "CORBA=3A=3ABoolean IEV=5FPRO=3A=3A=5Fimpl=5FEventMngrView=3A=
=3A=5Fdispatch=28GIOP=5FS&
giop=5Fs=29=22=2E The execution point is on the if ( giop=5Fs=2Erespons=
e=5Fexpected=28=29 ) { line
of the following code (i=2Ee after the call to my implementation=2C as =
one would
expect=3A
if=28 !strcmp=28giop=5Fs=2Eoperation=28=29=2C "notifyEvents=22=29=
) {
=20
IEV=3A=3ACombinedEvents arg=5Fp=5Fdata=3B
=20
arg=5Fp=5Fdata <=3C=3D giop=5Fs=3B
=20
giop=5Fs=2ERequestReceived=28=29=3B
=20
this-=3EnotifyEvents=28arg=5Fp=5Fdata=29=3B
=20
if=28 giop=5Fs=2Eresponse=5Fexpected=28=29 ) {
size=5Ft msgsize =3D (size=5Ft=29 GIOP=5FS=3A=3AReplyHeaderSi=
ze=28=29=3B
=20
giop=5Fs=2EInitialiseReply=28GIOP=3A=3ANO=5FEXCEPTION=2C (COR=
BA=3A=3AULong=29 msgsize=29=3B
=20
}
giop=5Fs=2EReplyCompleted=28=29=3B
return 1=3B
}
The problem appears when the the arg=5Fp=5Fdata object of class IEV=3A=3A=
CombinedEvents
goes out of scope=2E The destructor is called and eventually destroys a=
string
m=5Fname=2C which causes some heap checking debug code in MS C++ to fir=
e the
assertion off=2E I think it is designed to along the lines of preventin=
g heap
problems memory allocated from one DLL or run time library being destro=
yed by
another=2E=2E=2E=2E=2E
The IDL defintion of the Combined Events is not trivial=2E=2E=2E=2E it =
includes
sequences of strings=2C and a Variant type and other sequences=2E=2E=2E=
but the
destructor fails at the deallocation of the first string=2C which is th=
e first
member of the first none-empty sequence=2C (m=5Fname of OOLinfo in IDL =
desc=2E below=29=2C
in my case m=5Fevents is always a zero length sequence=2C and m=5FoolIn=
fos contains
one item=2E=2E=2E=2E
Remembering that my classes notifyEvents=28IEV=3A=3ACombinedEvents& arg=
=5Fp=5Fdata=29
implemtation does nothing (so I am definately not screwing the memory u=
p by
careless assigns=2E=2E=2E since it is passed by reference=29=2C I don't=
see why this
fails=2E=2E=2E=2E what can me and my code be doing wrong=3F
I have also put the breakpoint on the "arg=5Fp=5Fdata <=3C=3D giop=5Fs=3B=
=22 line and watched
the data being streamed in=2E=2E=2E then watched the memory as I step t=
hrough=2C and
nothing alters it=2E So why can't the IEV=3A=3ACombinedEvents destructo=
r clear itself
up properly=3F
Can anyone shed any light=3F
IDL file=3A
---------
module IEV
{
=2F
=2E
*** others defns deleted by me for brevity!!!! ***
=2E
=2E
/** Complete information of a limit violation *=2F
struct OOLinfo
{
string m=5Fname=3B
IBASE=3A=3ATime m=5FoolTime=3B
IBASE=3A=3ATime m=5FvalueTime=3B
OOLdetails m=5Fdetails=3B
}=3B
/** List of limit violations *=2F
typedef sequence=3COOLinfo=3E OOLinfos=3B
/******************=2F
/* CombinedEvents *=2F
/******************=2F
/** Combined events and OOLs *=2F
struct CombinedEvents
{
IBASE=3A=3ATime m=5FevPktTime=3B /=2F time context for the ev=
ents
RaisedEvents m=5Fevents=3B
OOLinfos m=5FoolInfos=3B
}=3B
}=3B
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F
James Eggleston tel=3A +49=
(0=29 6151
82570
VEGA Informations-Technologien GmbH fax=3A +49 (0=29 6151 =
825799
Julius-Reiber Strasse 19 =20
james=2Eeggleston=40vega=2Ede
64293 Darmstadt www=2Eveg=
a=2Ede or=20
www=2Evega=2Eco=2Euk =20
This transmission is intended for the named addressee only=2E It contai=
ns
information which may be confidential and which may also be privileged=2E=
Unless
you are the named addressee (or authorised to receive it for the addres=
see=29 you
may not copy or use it=2C or disclose it to anyone else=2E If you have =
received this
transmission in error please notify the sender immediately=2E =
=20
=20
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F
=