Hi,
attached is a patch for orb/poa_impl.cc (against 2.3.12, issue looks to
be there in RC3 too)
The problem is in MICOPOA::ObjectId::ObjectId's constructor. It doesn't
initialize the idlength member, which results in a crash in some cases
compiled under VC8 as a release version. (debug initializes to 0 so
problem doesn't appear in debug version). f.eg. at the end of
MICOPOA::POA_impl::invoke() is this (line 3319 in my poa_impl.cc):
1 POAObjectReference por2(poa, obj);
2 assert (por2.is_legal());
3 InvocationRecord_var ir = new InvocationRecord (id, &por2, req, pr);
where #1 initializes (or more like doesnt) por2's member oid with its
default constructor, and #3 uses ObjectId's copy constructor on that.
and the copy constructor,
MICOPOA::ObjectId::ObjectId (const ObjectId & id, bool copy)
blindly uses memcpy on the null pointer if idlength is non-zero
(uninitialized in this case).
This results in crashes, at least when compiled with Visual Studio 2005.
Someone might also want to look at the copy constructor, it doesn't
check the pointer members, i wonder if thats intentional or for performance.
The patch simply makes the constructor initialize the idlength to 0.
--
Arne Pajunen
Software Engineer
OpenTTCN Oy, Test and Test Control Components for Test System Vendors
Web: http://www.openttcn.com
--- mico-2.3.12/orb/poa_impl.cc 2006-07-31 12:57:50.109375000 +0300
+++ ot.win32/orb/poa_impl.cc 2006-07-31 12:24:44.640625000 +0300
@@ -425,6 +425,7 @@
octets = NULL;
oid = NULL;
own = true;
+ idlength = 0;
}
MICOPOA::ObjectId::ObjectId (const ObjectId & id, bool copy)
_______________________________________________
Mico-devel mailing list
[email protected]
http://www.mico.org/mailman/listinfo/mico-devel
