[omniORB] COMM_FAILURES and memory corruption
Ralf Hupfer
hupfer@ivi.fhg.de
Wed Nov 6 12:39:00 2002
Hi Duncan,
As I posted in another message today, the problem might be already
solved by a bugfix for the version 3.04, which is not included in the last
binary release at www.uk.research.att.com/omniORB. I am going to
compile version 3.05 and try to reproduce the error.
> On Tuesday 5 November, "Ralf Hupfer" wrote:
>
> > Is there a possibility that omniORB causes memory corruption when an
> > operation throws an exception?
>
> I think it's very unlikely, since nobody else has ever reported
> anything like that, but nothing's impossible.
>
> > I am using an interface that takes an in-, out- and inout-parameter. Both
> > the in- ind inout-parameters are nested sequences. The problem is
> > caused by the in-parameter, which is allocated on the heap and passed
> > to the method by the according _var-type. If the operation succeeds,
> > everything is fine, but if an COMM_FAILURE occurs the in-parameter
> > seems to be corrupted afterwards (I checked if with NUMEGA
> > DevPartner Studio). It shows a "dangling pointer" in
> > mySequence::`scalar deleting destructor'.
>
> Could it be that you have got something wrong about your memory
> management, which only shows up in the case that an exception is
> thrown?
>
> > I am using omniORB3.04 on Windows2000, VisualC++ 6.0 and Numega
> > DevPartner Studio. However, it's not the first time that Numega reveals
> > memory errors in the omniORB libraries for Windows ...
>
> Check that the debugging settings of your application and the omniORB
> build match each other. Windows can be very funny about such things.
>
> What other memory errors does Numega find?
>
I discovered some "dangling pointers" in a very early 3.0x version of
omniORB. Most of them I could eliminate, but not all. Should already be
covered by bugfixes.
Cheers
Ralf