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

[Duncan Grisby]

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 --