[omniORB] Help with allocating and deallocating - Try again

[David Hyde]

I posted this message last week, but I don't think that it got through, so
I'll try again.  Apologies if people get this twice:



Take a look at these code snippets below.  I think that they summarise what
I'm doing.



// The Session object.  This is declared globally in the cpp file
CBSession_ptr g_pSession;


// Later on we see if we have a connection to g_pSession
if (CORBA::is_nil(g_pSession))
{
	...

// At this time g_pSession is nil so we now try to create one
// We use a Factory object to spawn g_pSession.  The factory object was
created by a third program and
// its reference given to this process via its IOR.  The factory object
creates a session object for us and returns us
// the handle.  It is done this way because because several clients may be
asking the same factory object to create
// their own Session objects for them.

			g_pSession =
CBSession::_duplicate(pSessFactory->create());
			if (CORBA::is_nil(g_pSession)
			{
				// of course it isn't...
 				DoPanic(TRUE);
                        }

// Later still we've finished with g_pSession, so I get rid of it.
// I don't use delete and I don't set it to to NULL because the
documentation says not to do
// this with CORBA pointers		
CORBA::release(g_pSession);


// Now we want to use g_pSession again, but we have to have a new one made
for us because we've got rid of the
// old one.  We do this again.
if (CORBA::is_nil(g_pSession))
{
	...


I would have thought that is_nil should return TRUE, but it returns FALSE.
When I try to use the g_pSession object that I now think is valid the
program crashes.  I've wondered if I am doing something to screw up the
reference counting, so I tried CORBA::release on g_pSession twice in the
above code.  Stepping into the OmniOrb code, during the first release(), I
see that g_pSession's reference count is two.  If I do the double release,
though, the CORBA::is_nil call throws an exception.  What I can say is that
the first call to release is definitely causing the Session object's
destructor to be called.

Am I doing something wrong with my object lifetime management?  Please could
someone enlighten me.

Many thanks



David