[omniORB] basic ORB usage and Valgrind showing issue

[Sean Parker]

Hello - 

  I'm using Valgrind for my testing, and have been 
using it quite awhile but I need to resolve a long-standing

issue I've been seeing, and was hoping someone could point 
me to what I'm doing wrong... (I've been told on this 
list Valgrind has been used with OO - so I presume it's my
issue...) or if I need to supress this in Valgrind?

1) My main is this:
<CODE>
    try{
	CORBA::ORB_var orb = 
          CORBA::ORB_init( 0, NULL, NULL, NULL );
	CORBA::Object_var obj = 
          orb->resolve_initial_references("RootPOA");
	PortableServer::POA_var poa = 
          PortableServer::POA::_narrow(obj);

	PortableServer::POAManager_var pman = 
          poa->the_POAManager();
	pman->activate();
	sleep(3);
	orb->destroy();
    }catch(...){
    }
</CODE>

2) Valgrind shows this error: (stuff snipped for brevity - 
 I'm retyping from another machine)

<VALGRIND OUTPUT>

	Syscall param write(buf) points to unitialized bytes(s)
	  at ... write(in /lib/libpthread-0.10.so)
	  at ... omni_thread::start()
	  at ... omniAsynchInvoker::insert(omniTask*)
	  at ... omni::giopServer::activate()
	  at ... omni::giopServer::start()
	  at ... omni::omniObjAdapter::adapterActive()
	  at ... initialise_poa()
	  at ... omni::omniOrbPOA::rootPOA(int)
	  at ... omni::resolveRootPOAFn()
	  at ... omni::resolvePseudo(char const*, unsigned)
	  at ... omni::omniInitialReferences::resolve(char const*,
unsigned)
	  at ... omniOrbORB::resolve_initial_references(char
const*)
          ...
	Address so-and-so is on thread 1's stack

</VALGRIND OUTPUT>

3) Valgrind command line is this:

/home/separke/valgrind/valgrind-2.4.0/coregrind/valgrind
--quiet \
  --show-below-main=yes --log-fd=1 --tool=memcheck
--leak-check=full\
  --suppressions=... /home/separke/simi/bin/ORBTest 1
--logfile... 

4) ldd of my main is this:

  libomnithread.so.3
  libomniORB4.so.0
  libxerces-c.so.25
  libpthread.so.0
  libdl.so.2
  libstdc++.so.5
  libm.so.6
  libgcc_s.so.1
  libc.so.6
  /lib/ld-linux.so.2

Using RH Linux 2.4.20-6, gcc 3.2.2 Feb 2003
I did try traceLevel=40 with no interesting information
(looks good)

5) Also, a related question is:

Is there a problem with initing the orb, getting
NameService and registering
things, and *then* activating the RootPOA? Could that cause
other hidden issues
that may not be accounted-for, but it works anyway, in
violation of some
intended ORB design/sequence?


Thanks in advance for your patience and response...
  God Bless
    Sean




God Bless 
    Sean Parker 





		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free. 
http://music.yahoo.com/unlimited/