[omniORB] heap corruption in debug build

[Andrew Buza]

I'm using omniORB-4.1.0 in a DLL built with msvc 2005 (8.0). I'm
getting the messages "Heap block at 242BA858 modified at past
requested size of 64" and "Invalid Address specified to
RtlValidateHeap( 03080000, 242BA860 )" and hitting a breakpoint in
_RtlIsValidHeapPointer when CORBA objects are deleted .

I understand that this is usually the result of mixing DLLs using
different run-time libraries, but I've checked to make sure that my
project is set to use the /MDd (multithreaded debug DLL) flag, and
that I'm linking to the debug versions of the omniORB libraries.

It only happens occasionally, and I haven't found a way to
consistently reproduce the problem. Is it possible that the host
application could be causing this? I see calls into it on the call
stack between the exit of one of my functions and 'operator delete' in
msvcr80d.dll.

Does anyone know what the problem might be? Even knowing that it isn't
an issue with omniORB itself (and is instead, e.g., a configuration
problem) would be helpful.

[Martin Trappel]

Post by Andrew Buza
I'm using omniORB-4.1.0 in a DLL built with msvc 2005 (8.0). I'm
getting the messages "Heap block at 242BA858 modified at past
requested size of 64" and "Invalid Address specified to
RtlValidateHeap( 03080000, 242BA860 )" and hitting a breakpoint in
_RtlIsValidHeapPointer when CORBA objects are deleted .
I understand that this is usually the result of mixing DLLs using
different run-time libraries, but I've checked to make sure that my
project is set to use the /MDd (multithreaded debug DLL) flag, and
that I'm linking to the debug versions of the omniORB libraries.
It only happens occasionally, and I haven't found a way to
consistently reproduce the problem. Is it possible that the host
application could be causing this? I see calls into it on the call
stack between the exit of one of my functions and 'operator delete' in
msvcr80d.dll.
Does anyone know what the problem might be? Even knowing that it isn't
an issue with omniORB itself (and is instead, e.g., a configuration
problem) would be helpful.

I have very occasionally seen this behavior when I had some bugs in my
CORBA/omniORB code related to CORBA memory management. That is, using a
_var type somewhere where I should have used _ptr or something, double
deletions, returning a free'd string from a CORBA Method, etc. - I
really can't remember exactly.

Btw. you only get this message in debug because it's only checked there.
In the release build you App may just crash or continue doing something
wrong ...

br,
Martin