[omniORB] Using omniORB libraries with Visual C++ 2003/7.1 (memory management issues?)

Maks Verver m.verver at student.utwente.nl
Sun May 23 20:46:08 BST 2004

Hi everyone,

I'm trying to make a debug build with the Visual C++ 7.1 compiler and the
latest omniORB 4.0.3 binaries. I use (ofcourse) the debug libraries:
omniORB403_rtd.lib, omnithread30_rtd.lib and  omniDynamic403_rtd.lib.
However, there seem to be memory related problems. For example, the
following simple application which prints out the stringified nil reference
does not work:

---------------- >8 -------------------------------- >8 ----------------
#include <iostream>
#define __WIN32__
#define __x86__
#include <omniORB4/CORBA.h>

int main(int argc, char *argv[])
    CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
    CORBA::String_var ior = orb->object_to_string(CORBA::Object::_nil());
    std::cout << (const char*)ior << std::endl;
---------------- >8 -------------------------------- >8 ----------------

The problem is that I use the String_var object. It receives a buffer
allocated by omniORB and frees it when it goes out of scope. The problem is
that it uses delete[] to free the memory, which is only valid for memory
allocated from the application's local heap, while the memory has obviously
been allocated by the omniORB library. This is the infamous
_CrtIsValidHeapPointer check that failes.

I can reproduce the error by making this procedure explicit:

    char *ior = orb->object_to_string(CORBA::Object::_nil());
    std::cout << (const char*)ior << std::endl;
    delete[] ior; // debug assertion fails!

However, the following does work correctly, because this time, the memory is
freed by the omniORB library (that also allocated it in the first place):

    char *ior = orb->object_to_string(CORBA::Object::_nil());
    std::cout << (const char*)ior << std::endl;
    CORBA::string_free(ior); // ok.

The release build (using the non-debug omniORB libraries) doesn't complain,
but I suspect that is not because the code is correct, but rather because it
doesn't do any assertion checking anymore.

Now this example was not the real application. In my real application, I
have a lot of places where I use String_var objects that result in the
problems I described when I go into debug mode. With a release build, I get
all sorts of other run-time errors, that I find pretty hard to track down
without the proper debug symbols.

Both the mailing list and the Wiki contain some information about this kind
of errors, but none show a solution beyond 'use the debug libraries with
debug builds'. Is this a known problem? Am I doing something wrong? Has
anyone else tried and succeeded to build omniORB applications with Visual
C++ 7.1? I hope anyone can help me out; thanks in advance!

Kind regards,
Maks Verver.

More information about the omniORB-list mailing list