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

[Sendil_Natarajan at amat.com]

Hi Duncan,

I would say that that is actually good evidence that the problem is in your usage of omniORB and Orbix, not in both of the CORBA implementations. Why would two totally separate CORBA implementations that share no code have exactly the same memory leak bug?
[Sendil] - Our code is very simple and a snapshot of which has been shared below. We got confirmation from Orbix that it is an issue with the CORBA thread management which doesn't release memory after executing a request and it with holds that memory for performance benefit.
They even reproduced this issue with their own program to rule out any issues in our implementation. They agreed to do a fix on their part to overcome the case.

The common factor is your code, not the fact that both omniORB and Orbix developers have read the same specification documents and implemented them.
[Sendil] - It is really strange to see that both Omni and Orbix exhibited the behavior. We did through analysis on our code part and we couldn't find anything abnormal in our code. So, we believe it is something to do with some common CORBA library stuff that both Omni and Orbix uses.

That said, if you can share a minimal example program that exhibits the leak, it can be looked into. At the moment, there is nothing but a vague description of the problem.
[Sendil] - Please see the snapshot of our code

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 initialization
     CORBA::ORB_var orb;
     orb = CORBA::ORB_init(argc,argv,"omniORB4",options);

     /// CORBA object creation
     GPSServerManager _var gpsServer;
     gpsServer = GPSServerManager::_narrow(obj); string tableName = “testable”;

    /// gets huge string result from CORBA Server
   TestResult* testResult = gpsServer->getTableInfo(tableName);

    /// release the interface structure
    If(testResult)
   {
        /// print table info and then delete the result
        delete testResult;
    }

    /// clear CORBA resource
    orb->destroy();
    free(gpsServer);
}

Omni Server:
-------------------

/// Server side API function which constructs the string result
TestResult* GPSServerManager:: getTableInfo(const char* tableName)
{

        TestResult* testResult = new TestResult();

        /// gets the database table info for the given table name
        int columns = getDataBaseTableColumnCount(tableName);

       int rows = getDataBaseTableRowCount(tableName);

      testResult -> Rows.length(rows);

      /// the size of the string result will vary based upon the number of rows and columns of the table
      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 <duncan at grisby.org>
Sent: Tuesday, October 2, 2018 8:26 PM
To: Sendil Natarajan <Sendil_Natarajan at amat.com>; omniorb-list at omniorb-support.com
Subject: Re: [omniORB] [External] Re: OMNIORB compiled in gcc 4.8.3 version is leaking memory

On Mon, 2018-10-01 at 06:34 +0000, Sendil via omniORB-list wrote:

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

I would say that that is actually good evidence that the problem is in your usage of omniORB and Orbix, not in both of the CORBA implementations. Why would two totally separate CORBA implementations that share no code have exactly the same memory leak bug?  The common factor is your code, not the fact that both omniORB and Orbix developers have read the same specification documents and implemented them.

That said, if you can share a minimal example program that exhibits the leak, it can be looked into. At the moment, there is nothing but a vague description of the problem.

Duncan.

--
Duncan Grisby <duncan at 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.