Hi Arne,
thanks for you patch. I've merged it to the latest source tree. It is
interesting that you hit this issue while using VC8. Have you also tried
to run your test with any other supported compiler? I think that ObjectId
ctors does not check for NULL pointers since they silently assumes sane
ObjectId parameters. It might be interesting to see the test case which
observed this issue.
Thanks,
Karel
On Mon, 7 Aug 2006, Arne Pajunen wrote:
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
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
_______________________________________________
Mico-devel mailing list
[email protected]
http://www.mico.org/mailman/listinfo/mico-devel
