Destroying ORB(Visibroker)
Nithyanandham
Hello,
When the purify test was done in our code, we find that there is a
memory leak due to the memory allocation by " CORBA::ORB_init(argc,
argv);".....How do you destroy the ORB object?
The sequence is as follows :-
1. ORB is running now.
2. The process is killed with "kill -15 " .(UNIX )
3. In the signal handler for the signal, shutdown( ) is called.
4. If we pass "TRUE" as a parameter for shutdown( ), it is hanging at
this call.So, we passed "FALSE".
5. The signal handler returns and the ORB is out of run.
6. Now we call the release( ) method.
Still the memory leaks are there. We are using Visibroker 4.0. We
tried using destroy( ) before the step 6....But, we find that it is not
in Visibroker 4.0....I hope the destroy( ) only does the cleanup
activities. Then what is the alternative for destroy( ) in Visibroker.
What is the solution for this?
Regards,
Nithyanand.
Jim Melton
"Nithyanandham" <m.nithy...@blr.spcnl.co.in> wrote in message
news:3ADDA2B6...@blr.spcnl.co.in...
>
> Hello,
> When the purify test was done in our code, we find that there is a
> memory leak due to the memory allocation by " CORBA::ORB_init(argc,
> argv);".....How do you destroy the ORB object?
First of all, not all memory leaks are serious. A leak is not a problem if
it doesn't recur (kind of like a pipe with a hole in it that never has water
flowing through it). Purify will typically report leaked memory for things
in the environment (argv, envp). It is possible to leak memory for singleton
objects. However, if the leak is of a singular object at program
termination, don't worry about it.
> The sequence is as follows :-
>
> 1. ORB is running now.
> 2. The process is killed with "kill -15 " .(UNIX )
> 3. In the signal handler for the signal, shutdown( ) is called.
> 4. If we pass "TRUE" as a parameter for shutdown( ), it is hanging at
> this call.So, we passed "FALSE".
> 5. The signal handler returns and the ORB is out of run.
> 6. Now we call the release( ) method.
>
> Still the memory leaks are there. We are using Visibroker 4.0. We
> tried using destroy( ) before the step 6....But, we find that it is not
> in Visibroker 4.0....I hope the destroy( ) only does the cleanup
> activities. Then what is the alternative for destroy( ) in Visibroker.
>
> What is the solution for this?
Since you program is terminating (right? why else would you call shutdown()
??), don't worry about it. The OS will reclaim your "leaked" memory when
your process goes away. This is not a problem worth expending your resources
on.
Michi Henning
> > Hello,
> > When the purify test was done in our code, we find that there is a
> > memory leak due to the memory allocation by " CORBA::ORB_init(argc,
> > argv);".....How do you destroy the ORB object?
>
> First of all, not all memory leaks are serious. A leak is not a problem if
> it doesn't recur (kind of like a pipe with a hole in it that never has water
> flowing through it). Purify will typically report leaked memory for things
> in the environment (argv, envp). It is possible to leak memory for singleton
> objects. However, if the leak is of a singular object at program
> termination, don't worry about it.
I disagree -- see below.
> > The sequence is as follows :-
> >
> > 1. ORB is running now.
> > 2. The process is killed with "kill -15 " .(UNIX )
> > 3. In the signal handler for the signal, shutdown( ) is called.
> > 4. If we pass "TRUE" as a parameter for shutdown( ), it is hanging at
> > this call.So, we passed "FALSE".
> > 5. The signal handler returns and the ORB is out of run.
> > 6. Now we call the release( ) method.
> >
> > Still the memory leaks are there. We are using Visibroker 4.0. We
> > tried using destroy( ) before the step 6....But, we find that it is not
> > in Visibroker 4.0....I hope the destroy( ) only does the cleanup
> > activities. Then what is the alternative for destroy( ) in Visibroker.
> >
> > What is the solution for this?
The solution is to call ORB::destroy() after the run loop terminates. That
should clean up everything (provided that the ORB really doesn't drop memory).
> Since you program is terminating (right? why else would you call shutdown()
> ??), don't worry about it. The OS will reclaim your "leaked" memory when
> your process goes away. This is not a problem worth expending your resources
> on.
This may be true in an OS such as UNIX, but is not true in general. In
particular, for many embedded environments with hard memory, if you neglect
to deallocate something, it's permanently gone, never to be reclaimed by
anything. Even in non-embedde environments with virtual memory, this can
still happen. Windows is the best example. (Ever wonder why you end up
having to reboot many Windows machines after a day or two? It's caused
by buggy programs that don't deallocate memory correctly when they terminate,
eventually depriving the kernel of all memory.)
In general, I find that it is worth it to pay attention to memory leaks
reported by Purify. At worst, you'll simply remove a harmless memory leak.
At best, you will realize that the code didn't behave quite the way you
thought it did and end up fixing some bugs in the process.
Cheers,
Michi.
--
Michi Henning +61 7 3324 9633
Object Oriented Concepts - An IONA Company +61 4 1118 2700 (mobile)
Suite 4, 8 Martha St +61 7 3324 9799 (fax)
Camp Hill 4152 michi....@iona.com
Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi
Nithyanandham
Michi Henning wrote:
> The solution is to call ORB::destroy() after the run loop terminates. That
> should clean up everything (provided that the ORB really doesn't drop memory).
We are using Visibroker 4.0...It seems that ORB::destroy() is not available in
this ORB.
We tried using this method as given below :-
1. CORBA::ORB_var orb;
// .............
//.............
orb->destroy( ) ;
2. CORBA::ORB_ptr orb;CORBA::
//...........
//..........
orb->destroy( ) ;
3. ORB::destroy();
4. CORBA::ORB_var orb;
//............
//...........
CORBA::destroy( orb);
but it gives error. I think this is available in ORBacus , but not in Visibroker.
Then what is the solution.
--Nithyanand.
Gert Kello
shutdown()
> ??), don't worry about it. The OS will reclaim your "leaked" memory
when
> your process goes away. This is not a problem worth expending your
resources
> on.
There is another side of the story: when You are using library which
causes memory leaks, testing and finding the ones You are made is much
more complicated - You have to figure out on every item whether it is
caused by Your program or by library.
Gert
Nithyanandham
Gert Kello wrote:
Purify clealy shows that it leaks due to the ORB_init( ) call , not due to
my other part of the code.
Through the stack frame purify gives, we can infer this.
--Nithyanand.
Gert Kello
Yes, I see. The thing I wanted to say, is that even if these memory
leaks are harmless (I'm not saying they are), they make finding and
fixing other leaks harder... So, a memory leak is bad thing in any
circumstances...
Gert
Michi Henning
> Purify clealy shows that it leaks due to the ORB_init( ) call , not due to
> my other part of the code.
>
> Through the stack frame purify gives, we can infer this.
Well, ORB::destroy() undoes what ORB_init() does, so that makes sense.
Michi Henning
> Michi Henning wrote:
>
> > The solution is to call ORB::destroy() after the run loop terminates. That
> > should clean up everything (provided that the ORB really doesn't drop memory).
>
> We are using Visibroker 4.0...It seems that ORB::destroy() is not available in
> this ORB.
>
> We tried using this method as given below :-
>
> 1. CORBA::ORB_var orb;
> // .............
> //.............
> orb->destroy( ) ;
The following must work in a compliant ORB:
CORBA::ORB_var orb;
orb = CORBA::ORB_init(argc, argv);
orb->destroy();
If it doesn't, the ORB needs fixing. (But I'm finding it difficult to believe
that ORB::destroy() is missing...)
Mogens Hansen
"Michi Henning" <mi...@ooc.com.au> wrote in message
news:Pine.HPX.4.05.101041...@bobo.ooc.com.au...
>
> The following must work in a compliant ORB:
>
> CORBA::ORB_var orb;
> orb = CORBA::ORB_init(argc, argv);
> orb->destroy();
>
> If it doesn't, the ORB needs fixing. (But I'm finding it difficult to
believe
> that ORB::destroy() is missing...)
>
I can asure you that ORB::destroy is missing in Visibroker for C++ V4.0.
I filed a bug-report on that issue shortly after Visibroker V4.0 was
released.
I was told by Borland Support, that Visibroker did not leak, when the
program terminated after shutdown was called.
I can't detect any memory leak wih Numega BoundsChecker when running the
following progam:
main(int argc, char* argv[])
{
try
{
// Initialize the ORB and BOA
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
}
catch(const CORBA::Exception& e)
{
Cerr << e << endl;
return(1);
}
return 0;
}
Of course I would by far prefer that ORB::destroy was implemented - at least
for the sake of compatibility.
Kind regards
Mogens Hansen
Nithyanandham
>
> I can asure you that ORB::destroy is missing in Visibroker for C++ V4.0.
>
> I filed a bug-report on that issue shortly after Visibroker V4.0 was
> released.
> I was told by Borland Support, that Visibroker did not leak, when the
> program terminated after shutdown was called.
We used shutdown( ) with "true" as an argument. But it keeps on waiting for very
longer time. So we just passed "false" and it returns quickly and the ORB comes
out of run......But again leaks. ( I have specified this in my first post
itself)
..............
If we pass "TRUE" as a parameter for shutdown( ), it is hanging at
this call.So, we passed "FALSE".
.............
I strongly believed that shutdown(true) will work . But
waiting...waiting...waiting.... when it is called. So, what to do ?
--Nithyanand.
Michi Henning
> We used shutdown( ) with "true" as an argument. But it keeps on waiting for very
> longer time. So we just passed "false" and it returns quickly and the ORB comes
> out of run......But again leaks. ( I have specified this in my first post
> itself)
> ..............
> If we pass "TRUE" as a parameter for shutdown( ), it is hanging at
> this call.So, we passed "FALSE".
> .............
> I strongly believed that shutdown(true) will work . But
> waiting...waiting...waiting.... when it is called. So, what to do ?
Where are you calling shutdown(true) from? From within an operation on the
servant? If so, that shouldn't work at all and raise a BAD_INV_ORDER
exception. If you call it from a signal handler, that's unlikely to work too...
Mogens Hansen
>
>
>
> We used shutdown( ) with "true" as an argument. But it keeps on waiting
for very
> longer time. So we just passed "false" and it returns quickly and the ORB
comes
> out of run......But again leaks. ( I have specified this in my first
post
> itself)
> ..............
> If we pass "TRUE" as a parameter for shutdown( ), it is hanging at
> this call.So, we passed "FALSE".
> .............
> I strongly believed that shutdown(true) will work . But
> waiting...waiting...waiting.... when it is called. So, what to do ?
I noticed that ORB::destroy was missing from Visibroker 4.0, while reading
Michi Henning and Steve Vinosky's very fine book.
I was not able to make the server from chapter 3 close without memory-leak.
I modified the server code (with help from, as far is I remember, Douglass
Schmidt or Steve Vinosky - thank you very much).
Note the calls to "poa->destroy" and "orb->destroy" in the end of the
server.
As I remeber it, the server ran on Windows NT without any leaks by NuMega
BoundsChecker when it was build with Borland C++Builder V5.0 Enterprise,
Visibroker V4.0.2. But when I build it now, "poa->destroy" throw a
OBJECT_NOT_EXIST exception - that's like I remembered it! But anyway -
BoundChecker does not report any leaks.
I have also tested it with The ACE Orb (TAO) V1.1.0 with both Borland
C++Builder V5.0 and Microsoft Visual C++ V6.0 without any leak (except a few
in the Microsoft RTL, which seem to be present in any console application) .
Ok - perhaps that was a bit fluffy - but it's the best I can do now.
I hope that it gives you some ideas.
Kind regards
Mogens Hansen
#if /*defined(_VIS_STD) &&*/ defined(_MSC_VER) && (1200 == _MSC_VER)
// Inprise Visiroker (V4.0) and Microsoft Visual C++ V6.0
#pragma warning( disable : 4290 ) // C++ Exception Specification ignored
#pragma warning( disable : 4250 ) // 'class1' : inherits 'class2::member'
via dominance
#endif
#include <time.h>
#include <iostream>
#include "server.h"
#ifdef _WIN32
#include <wincon.h>
#endif
using namespace ch3;
using namespace std;
TimeOfDay
Time_impl::get_gmt() throw(CORBA::SystemException)
{
time_t time_now = time(0);
struct tm * time_p = gmtime(&time_now);
ch3::TimeOfDay tod;
tod.hour = time_p->tm_hour;
tod.minute = time_p->tm_min;
tod.second = time_p->tm_sec;
return tod;
}
#ifdef _WIN32
// Platfor specific code for shutting down the ORB
namespace
{ // start of unnamed namespace
CORBA::ORB_ptr orb_;
BOOL WINAPI HandlerRoutine(DWORD /*dwCtrlType*/)
{
try {
if(!CORBA::is_nil(orb_)) {
#if defined(TAO_MAJOR_VERSION)
#if !((1 == TAO_MAJOR_VERSION) && (1 == TAO_MINOR_VERSION) && (0 ==
ACE_BETA_VERSION))
#error Verify if the problem is still present
#endif
// This is TAO V1.1.0
// Since this functions is called from a thread, which is not an ACE thread
// Some thread-local storage is allocated, but not released
// As a work-around the "CORBA::Environment" object is allocated on the
stack
CORBA::Environment ACE_TRY_ENV;
orb_->shutdown(false, ACE_TRY_ENV);
#else
// Standard OMG CORBA
orb_->shutdown(false);
#endif
}
}
catch(...) {
}
::SetConsoleCtrlHandler(HandlerRoutine, FALSE);
return TRUE;
}
} // end of unnamed namespace
#endif
int
main(int argc, char * argv[])
{
try {
// Initialize orb
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
// Get reference to Root POA.
CORBA::Object_var obj
= orb->resolve_initial_references("RootPOA");
PortableServer::POA_var poa
= PortableServer::POA::_narrow(obj);
// Activate POA manager
PortableServer::POAManager_var mgr
= poa->the_POAManager();
mgr->activate();
// Create an object
Time_impl time_servant;
// Write its stringified reference to stdout
Time_var tm = time_servant._this();
CORBA::String_var str = orb->object_to_string(tm);
cout << static_cast<char*>(str) << endl;
#ifdef _WIN32
// platform specific code for copying the IOR to the clipboard
if(::OpenClipboard(NULL)) {
::EmptyClipboard();
HGLOBAL mem = ::GlobalAlloc(GMEM_DDESHARE,
(strlen(str)+1)*sizeof(char));
if(mem) {
::strcpy(static_cast<char*>(mem), str);
::SetClipboardData(CF_TEXT, mem);
}
::CloseClipboard();
}
// platform specific code for shutting down the server
orb_ = static_cast<CORBA::ORB_ptr>(orb)/*.ptr()*/;
::SetConsoleCtrlHandler(HandlerRoutine, TRUE);
#endif
// Accept requests
orb->run();
// Clean up
poa->destroy(1, 1);
#if !defined(_VIS_STD)
// Visibroker for C++ V4.0 does not support
// CORBA_ORB::destroy as specified in CORBA V2.3
orb->destroy();
#endif
}
catch (const CORBA::Exception &) {
cerr << "Uncaught CORBA exception" << endl;
return 1;
}
return 0;
}