[omniORB] [External] Re: OMNIORB compiled in gcc 4.8.3 version is leaking memory

[Sendil_Natarajan at amat.com]

Hi Omni group,

Can you please provide any suggestion here? Our work is impacted because of this. We tried investigating it further but couldn't find any clue to fix this.

Thanks,
Sendil
-----Original Message-----
From: Sendil Natarajan
Sent: Thursday, August 30, 2018 10:46 AM
To: Duncan Grisby <duncan at grisby.org>; omniorb-list at omniorb-support.com
Subject: RE: [External] Re: [omniORB] OMNIORB compiled in gcc 4.8.3 version is leaking memory

Hi Duncan,

As per your suggestion we are trying to build the Omni using the latest Omni 4.2.2 libraries. We do have two versions of Omni, one is built using Xlc compiler and another is using gcc compiler both in AIX 6.1 machine.

The Xlc version is
IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07)

Python version is:
Python 2.7.12 -  64 bit

We met an error while compiling the Omni in Xlc version.
/disks/smithers3/checkpoints/DESTBASE/apfdev/HEAD/xlC-13.1-aix6-powerpc64/bin/omniidl -bcxx -p../../../src/lib/omniORB/python -I../../../idl -Wbdebug -Wba -p../../../src/lib/omniORB/python -I../../../idl -Wbdebug -v -ComniORB4 ../../../idl/Naming.idl
dir.mk:101: recipe for target 'omniORB4/Naming.hh' failed

We tried looking for any clue in the net but nothing helped. Can you please help us here?

We are not trying to build it in gcc and not sure we will succeed in it.

Thanks,
Sendil
-----Original Message-----
From: Duncan Grisby [mailto:duncan at grisby.org]
Sent: Wednesday, July 11, 2018 3:53 PM
To: Sendil Natarajan <Sendil_Natarajan at amat.com>; omniorb-list at omniorb-support.com
Subject: Re: [External] Re: [omniORB] OMNIORB compiled in gcc 4.8.3 version is leaking memory

On Thu, 2018-06-21 at 16:30 +0000, Sendil_Natarajan at amat.com wrote:

[...]
> 1. For each execution that is for each call of the getTableInfo method
> by the client, the CORBA server constructs a TestResult object. This
> object contains lots of string values which has a size of around 300
> MB.
> 2. The server returns the raw pointer of the TestResult object to the
> ORB.

That is the correct thing to do according to the rules of the CORBA C++ mapping.

> 3. I think, the Omni thread from the thread pool, which is used to
> handle the client request, makes another copy of the TestResult
> structure and passes the new pointer to the client

No, it doesn't. omniORB does not copy the value returned from the method.

> 4. The Omni thread which has the original TestResult structure is not
> deleted. As long as the thread is maintained in the threadpool the
> data is persisted.

omniORB does not hold anything like that in per-thread storage. Maybe the operating system or C++ runtime maintains a per-thread free list of unallocated memory blocks or something, but omniORB definitely does not.

[...]
> 7. The printed output of the raw pointer of TestResult in server and
> client shows that both are different. Which means the OmniORB creates
> an intermediate copy of the
>      TestResult structure which it keeps undeleted
>       Server created TestResult* address = 0x110af55d0
>
>       Client received TestResult* address = 0x111eee270

Presumably the client and server are in different processes here?  In that case, of course they have different pointers to the data. On the server side, the stub code generated by the IDL compiler marshals the data across the network then deletes the data. On the client side, it allocates space for the data and unmarshals it from the network. I suppose you could call that a "copy", but it is not a copy on the server side where you see a leak.

If the client and server are in the same process, then the pointer returned from the implementation method is directly passed to the caller. There is no data copying.

> 8. I haven't switched to 4.2.2 yet as we are not sure if 4.2.2 will
> solve the issue and thought to investigate further to understand the
> real root cause.
>
> Do you think 4.2.2 version will address this problem? Do you have any
> other thought on how to fix it?

The build fixes I refer to are not in the 4.2.2 release. They were made subsequent to 4.2.2, and have not yet appeared in a numbered release.
You need to get the snapshot of the current repository state:

http://omniorb.sourceforge.net/snapshots/omniORB-4.2-latest.tar.gz

I don't know if the incorrect build is pertinent to the problem you see, but it is plausible that it could be related. It is not a good use of time to try to diagnose this issue further before you try with the build fixes.

Duncan.

--
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --

The content of this message is APPLIED MATERIALS CONFIDENTIAL. If you are not the intended recipient, please notify me, delete this email and do not use or distribute this email.