[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


=