[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