HOST MACHINE and OPERATING SYSTEM: (tested on two platforms)
- Ubuntu Linux 10.04 (ACE/TAO 5.7.0 and 6.0.0)
- OpenSuse 11.3 (ACE/TAO 5.7.0)
TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
COMPILER NAME AND VERSION (AND PATCHLEVEL):
- gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 (Kernel: 2.6.32-31-generic-
pae i686)
THE $ACE_ROOT/ace/config.h FILE: config-linx.h
THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE:
- platform_linux.GNU (on ACE/TAO 6.0.0: valgrind=1)
BUILD METHOD USED: traditional makefile/project
CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/
default.features
AREA/CLASS/EXAMPLE AFFECTED:
- My own example attached below
- Affects the usage of long sequences
DOES THE PROBLEM AFFECT: EXECUTION
SYNOPSIS: A sequence of 20000 integers is transmitted via a simple
RPC and leads on the caller side to a rapid memory growth.
DESCRIPTION:
- My example consists of two idl files:
--> data.idl: defines a struct with a sequence of integers
--> rpc.idl: defines a simple rpc method with a Any type as method
parameter (Any contains later the sequence)
- I start a simple server, which implements the rpc interface and a
simple client which calls the rpc method in a loop
- The client causes continuous memory growth (untill my 4 GB RAM
are full :-) )
REPEAT BY:
- Run the naming service
- Run the server
- Run the client and observe your memory (e.g. with "top")
SAMPLE FIX/WORKAROUND:
- Unfortunately I did not found a workaround and "valgrind" did
not revealed any obvious leaks, but here is my simplified testing
example:
data.idl:
-----------
module data {
typedef sequence<unsigned long> list;
struct CommSequence {
list intSequence;
};
};
rpc.idl
---------
interface rpc {
oneway void update(in any user);
};
SERVER:
---------------
#include <iostream>
#include <tao/corba.h>
#include <orbsvcs/CosNamingC.h>
#include "rpcS.h"
class MyRPC: public POA_rpc {
public:
virtual void update(const ::CORBA::Any & user) {
std::cout << "UPDATE CALLED" << std::endl;
}
};
int main(int argc, char* argv[])
{
try {
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
// Get a reference to the Root POA.
CORBA::Object_var poa_obj = orb-
>resolve_initial_references("RootPOA");
PortableServer::POA_var poa = PortableServer::POA::_narrow(poa_obj);
poa->the_POAManager()->activate();
// CORBA Naming Service
CORBA::Object_var naming_context_object =
orb->resolve_initial_references("NameService");
CosNaming::NamingContext_var naming_context =
CosNaming::NamingContext::_narrow(naming_context_object.in());
CosNaming::Name name(1); name.length(1);
name[0].id = CORBA::string_dup("SequenceTest");
MyRPC myrpc;
naming_context->rebind(name, myrpc._this());
std::cout << "Server ready...\n\n";
orb->run();
} catch (CORBA::Exception& e) {
std::cerr << "CORBA Exception: " << e << std::endl;
}
return 0;
}
CLIENT:
------------
#include <iostream>
#include <tao/corba.h>
#include <orbsvcs/CosNamingC.h>
#include "rpcS.h"
#include "dataC.h"
#define LEAKTEST 1
int main(int argc, char* argv[]) {
try {
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
// CORBA naming service
CORBA::Object_var naming_context_object =
orb->resolve_initial_references("NameService");
CosNaming::NamingContext_var naming_context =
CosNaming::NamingContext::_narrow(naming_context_object.in());
CosNaming::Name name(1); name.length(1);
name[0].id = CORBA::string_dup("SequenceTest");
CORBA::Object_var my_object = naming_context->resolve(name);
rpc_var my_rpc = rpc::_narrow(my_object.in());
if (CORBA::is_nil(my_rpc)) {
std::cerr << "Unable to get hello reference" << std::endl;
return 1;
}
// Get a reference to the Root POA.
CORBA::Object_var poa_obj = orb-
>resolve_initial_references("RootPOA");
PortableServer::POA_var poa = PortableServer::POA::_narrow(poa_obj);
poa->the_POAManager()->activate();
data::CommSequence sequence;
#ifdef LEAKTEST
sequence.intSequence.length(200000);
#endif
int count = 3;
while (count-- > 0) {
CORBA::Any any;
any <<= sequence;
my_rpc->update(any);
usleep(200000);
}
orb->destroy();
} catch (CORBA::Exception& e) {
std::cerr << "CORBA Exception: " << e << std::endl;
}
return 0;
}
Please give me some advise: Did I misused something wrong, or have I
found a serious memory leak?
Thanks,
Alexej
Thanks for using the PRF form. I remember some memory leaks with oneways
in some cases, can you try 6.0.2 which you can obtain from
http://download.dre.vanderbilt.edu
Regards,
Johnny
thank you very much for your quick reply. I tested the current minor
release (ACE/TAO 6.0.2). Yes indeed, the memory leak is solved there.
I dug a bit deeper and it seems that the SVN Revision 93817 is the
relevant change for my problem. It was a bit difficult to find,
because the description says "Optimizations for growing unbounded
sequences..." which surely is a sort of description for a memory
leak. :-)
Regards,
Alexej