[omniORB] Memory Leaks with omniORB 4.1.1 for VC8 and MFC

[Martin Trappel]

Greetings!

I'm currently trying out omniORB 4.1.1.
* omniORB-4.1.1-x86-win32-vc8.zip
* Windows XP with Visual Stuido 2005 (VC8)

I have run into this:
When I compile the echo example with a VS2005 sample project (type:
Win32 console) with MFC support turned OFF, everything works fine.

When I compile the echo example with a sample project where MFC is
turned ON, I get reported a lot of memory leaks, even if no omniORB
calls are done, but only echoSK.cc is compiled + linked with the project.

I have added "return 0;" as the first line in both main functions to
cross check.

I suspect the memleak detection mechanism of VC8 gets confused/messed up
for the global initialization code of omniORB when I use MFC.
As the binaries are already compiled for VC8, I have little hope that
simply compiling it myself can resolve the problem ...

* Can anyone explain the behaviour?
* Can anyone give me a hint for a workaround ... not being able to use
omniORB in MFC context is really a bit awkward.

Memory leak output (snippet):
####
Detected memory leaks!
Dumping objects ->
{2209} normal block at 0x0044FD90, 35 bytes long.
Data: <IDL:omg.org/CORB> 49 44 4C 3A 6F 6D 67 2E 6F 72 67 2F 43 4F 52 42
{2208} normal block at 0x0044FD48, 12 bytes long.
Data: < D P D nD > 90 FD 44 00 50 FB 44 00 E8 6E 44 00
(...)
{56} normal block at 0x00355C98, 24 bytes long.
Data: < | > 20 CB 98 7C FF FF FF FF 00 00 00 00 00 00 00 00
Object dump complete.
###

thanks a lot!
- Martin

[Martin Trappel]

Post by Martin Trappel
Greetings!
I'm currently trying out omniORB 4.1.1.
* omniORB-4.1.1-x86-win32-vc8.zip
* Windows XP with Visual Stuido 2005 (VC8)
Win32 console) with MFC support turned OFF, everything works fine.
When I compile the echo example with a sample project where MFC is
turned ON, I get reported a lot of memory leaks, even if no omniORB
calls are done, but only echoSK.cc is compiled + linked with the project.
(...)

OK, I just found out that memory leak detection is actually only
available with MFC. That explains why I get no leaks reported with a
simple win32 app. ::)

Still, there remains the question: Are the reported leaks "real" leaks
or is there some misreporting because of ... ?

cheers,
Martin

[Martin Trappel]

Post by Martin Trappel

Post by Martin Trappel
Greetings!
I'm currently trying out omniORB 4.1.1.
* omniORB-4.1.1-x86-win32-vc8.zip
* Windows XP with Visual Stuido 2005 (VC8)
Win32 console) with MFC support turned OFF, everything works fine.
When I compile the echo example with a sample project where MFC is
turned ON, I get reported a lot of memory leaks, even if no omniORB
calls are done, but only echoSK.cc is compiled + linked with the project.
(...)

OK, I just found out that memory leak detection is actually only
available with MFC. That explains why I get no leaks reported with a
simple win32 app. ::)
Still, there remains the question: Are the reported leaks "real" leaks
or is there some misreporting because of ... ?

I have now confirmed that this is a problem of the MFC memory leak
detection.
In short: The MFC memory leak detection will kick in before other
modules that do not use MFC have been unloaded, thereby reporting false
leaks.

br,
Martin

[Martin Trappel]

Post by Martin Trappel

Post by Martin Trappel

Post by Martin Trappel
Greetings!
I'm currently trying out omniORB 4.1.1.
* omniORB-4.1.1-x86-win32-vc8.zip
* Windows XP with Visual Stuido 2005 (VC8)
Win32 console) with MFC support turned OFF, everything works fine.
When I compile the echo example with a sample project where MFC is
turned ON, I get reported a lot of memory leaks, even if no omniORB
calls are done, but only echoSK.cc is compiled + linked with the project.
(...)

OK, I just found out that memory leak detection is actually only
available with MFC. That explains why I get no leaks reported with a
simple win32 app. ::)
Still, there remains the question: Are the reported leaks "real" leaks
or is there some misreporting because of ... ?

I have now confirmed that this is a problem of the MFC memory leak
detection.
In short: The MFC memory leak detection will kick in before other
modules that do not use MFC have been unloaded, thereby reporting false
leaks.

I thought I might update this old issue of mine since I was now able to
find a solution for this ...

It's possible to switch the memory leak detection mechanism of MFC off,
by providing a 2nd DLL with a static object and some clever calls.
See:
http://groups.google.com/group/microsoft.public.vc.mfc/msg/e651b944da9c619d
and
http://groups.google.com/group/microsoft.public.vc.mfc/browse_frm/thread/e40ffe3da9c06692/0fb3b0fdd6951f4f

br,
Martin