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

[Bailey, Kendall]

Have you tried using the _var type?  It's designed to assist with reference counting and ensure things get cleaned up.  


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

    TestResult_var testResult( new TestResult );

    // Populate the testResult

    return testResult._retn();
}

This should result in the proper deletion of the testResult structure once it's returned to the client.  Using _var types is essential to exception-safe memory management.  

Cheers,
Kendall


-----Original Message-----
From: Sendil via omniORB-list [mailto:omniorb-list at omniorb-support.com] 
Sent: Friday, June 22, 2018 6:35 AM
To: duncan at grisby.org; omniorb-list at omniorb-support.com
Subject: Re: [omniORB] [External] Re: 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:

https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fomniorb.sourceforge.net%2Fsnapshots%2FomniORB-4.2-latest.tar.gz&data=02%7C01%7Cbaileyk%40schneider.com%7Ce0139f82e7684b80cead08d5d8345475%7Ce439976157cf420a98c2ca0f44ce8267%7C0%7C0%7C636652641660611878&sdata=xyWnXi%2B5iAGmCW1%2BRi7%2BZIyw8wO3tVTgec4ruZ5YHOs%3D&reserved=0

Does that still show the problem?

Duncan.

--
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.grisby.org&data=02%7C01%7Cbaileyk%40schneider.com%7Ce0139f82e7684b80cead08d5d8345475%7Ce439976157cf420a98c2ca0f44ce8267%7C0%7C0%7C636652641660611878&sdata=i5Tpyy1lzEfnJ%2Fdyv4ciMt4kiFZI5D7mH%2BH0FxCnUUs%3D&reserved=0 --

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.
_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.omniorb-support.com%2Fmailman%2Flistinfo%2Fomniorb-list&data=02%7C01%7Cbaileyk%40schneider.com%7Ce0139f82e7684b80cead08d5d8345475%7Ce439976157cf420a98c2ca0f44ce8267%7C0%7C0%7C636652641660611878&sdata=M42tTvy%2B3wgWZYv%2FYbcH9W4FzEWvNnFGy%2FmrQuKpIQw%3D&reserved=0