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

[Sendil_Natarajan at amat.com]

Hi Duncan,

As per your suggestion we built the Omni using the latest Omni 4.2.2 libraries in gcc and tested it. We are still seeing the memory growth issue. Our product has two versions one uses Omni and the other using Orbix. We tested the same scenario in Orbix to see if it’s a Omni specific or general issues in CORBA. As we expected, we did see the same memory growth in Orbix too, and that confirmed that this is something to do with the common CORBA thing. We raised a ticket with Orbix and they confirmed that it's an issue in the thread management which actually not releases the memory what it with holds and it does it for speed improvements. But that actually causing the process to consume more memory and at one point the process crashes due to memory saturation. Orbix agreed to investigate it further and do a fix.

So, is there a way that Omni can also look into the CORBA thread management and come up with a fix?

Thanks,
Sendil
-----Original Message-----
From: Sendil Natarajan
Sent: Friday, June 22, 2018 5:05 PM
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,

Any way you can help here?

Thanks,
Sendil
-----Original Message-----
From: Sendil Natarajan
Sent: Thursday, June 21, 2018 10:00 PM
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,

We have narrow downed the issue to the ORB implementation. The memory increase is happening because of the ORB threads which is holding the server returned structure undeleted. So, when more threads are created to handle the incoming client requests, each thread keeps the final result structure returned by server undeleted after sending the reply to client. This increases the memory footprint of the process.

For ex, the below is my omni implementation

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.
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 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.
5. I'm using threadPerConnectionPolicy = 0, threadPoolWatchConnection = 0 and maxServerThreadPoolSize = 100 6. The server process memory grows to 4 GB for the above setup. Decreasing the maxServerThreadPoolSize = 10 contains the memory growth and it stays around 1.2 GB 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 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?

Your help is very much appreciated.

Omni IDL:

Typedef sequence<string> Columns;
Typedef sequence< Columns > Rows;

Struct TestResult
{
      Rows table_rows;
}

Interface GPSServerManager
{
       TestResult getTableInfo(in string tableName); }

Omni Client:

int main(int argc, char * argv[])
{
CORBA::ORB_var orb;
orb = CORBA::ORB_init(argc,argv,"omniORB4",options);

GPSServerManager _var gpsServer;
gpsServer = GPSServerManager::_narrow(obj); string tableName = “testable”;
TestResult* testResult = gpsServer->getTableInfo(tableName);

If(testResult)
{
   // print table info
   delete testResult;
}

orb->destroy();
free(apfServer);
}

Omni Server:

TestResult* GPSServerManager:: getTableInfo(const char* tableName) {

TestResult* testResult = new TestResult();

// get the database table info for the give table int columns = getDataBaseTableColumnCount(tableName);
int rows = getDataBaseTableRowCount(tableName);

testResult -> Rows.length(rows);

for(int i = 0; Ii < rows; i++)
{
      testResult -> Rows[i].length(columns);

     for(int j = 0; j < columns; j++)
     {
                testResult-> Rows[i][j] = CORBA::string_dup(getDataBaseTableValue(tableName, i, j));
      }
}

return testResult;
}

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

On Thu, 2018-05-03 at 07:08 +0000, Sendil via omniORB-list wrote:
>
> I have a CORBA based client and server created using OmniORB. My Omni
> version is 4.2.0 (libomniORB420.a) and I have built the Omni using gcc
> version GNU gcc-4.8.3. I’m running the Omni in AIX 6.1 platform.

Why are you using 4.2.0 when 4.2.2 is available?

Regardless, there have been some changes since 4.2.2 to the AIX build that may be relevant. There is nothing specifically related to a memory leak, but there were previously some incorrect build options.

Please try the latest snapshot from here:

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

Does that still show the problem?

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.