[omniORB] rendezvouser error

[John Chesshir]

	That last email was an idiot's question.  Upon further
inspection, I realized the CPPFLAGS is a precompiler, not a compiler,
directive.  
	We have now set the CXXFLAGS and CFLAGS environment variables to
-ggdb (in case there are extras gdb needs).  We have cleaned out our
omniORB compile and started from scratch.  We passed the options
--disable-static and --enable-thread-tracing to the configure script.
We then recompiled our own code against the new omniORB shared objects.

	After all this we are still unable to step into the omniORB code
to find where that error message is coming from.  What are we missing?

-----Original Message-----
From: omniorb-list-bounces at omniorb-support.com
[mailto:omniorb-list-bounces at omniorb-support.com] On Behalf Of John
Chesshir
Sent: Friday, July 01, 2005 10:20 AM
To: Duncan Grisby
Cc: omniorb-list at omniorb-support.com
Subject: RE: [omniORB] rendezvouser error 


Duncan,
	Thanks for your reply.  
	I will write those test programs if I need to, but I would
rather step through the code first if I can.  I tried to set the
CPPFLAGS environment variable to -g and recompile omniORB, but I still
can't seem to step into the omniORB source files with gdb.  What am I
missing?

Thanks again,
John C

-----Original Message-----
From: Duncan Grisby [mailto:duncan at grisby.org] 
Sent: Monday, June 27, 2005 8:51 AM
To: John Chesshir
Cc: omniorb-list at omniorb-support.com
Subject: Re: [omniORB] rendezvouser error 


On Wednesday 22 June, "John Chesshir" wrote:

>     Here is some more info.  I tried putting the traceLevel
> environment variable to 40.  I have attached results from the Red Hat 
> Linux 7.0 server (server.bad) and the Red Hat Linux 7.2 2.96-128.7.2 
> server
> (server.good)  The only difference besides the IP address is that the
> bad one notes a failure so spawn a thread and then the cannot create
> rendezvouser message, while the good one notes a successful thread
> startup and a rendezvouser task set up.  
>     Also, I got information on the hardware.  Red Hat 7.0 is running
on
> an IBM x390 server, while the other is running on a dell PIII desktop.
>     I am thinking this may have to do with Redhat or the Dell not
being
> able to spawn threads, although I do see two processes with my
server's
> name on them where there have generally been three on startup ever
since
> we went to omniORB.  I always assumed the extra two processes were
Linux
> threads, although the trace only shows one thread being (or trying to
> be) created.  Is that other sub-process something else?  Can anyone 
> confirm, deny, or give extra thoughts?

The "cannot create a rendezvouser" message is indeed a sign that omniORB
was unable to start a thread. You need to understand why that is. I'd
suggest trying to write a simple program that starts a thread, first
with plain pthread calls, then with omnithread, to see whether that
works.

omniORB definitely works fine on RedHat 7.0 for Intel processors, but I
don't know about the x390.

On RedHat 7 era linux, you see one process in the process listing for
each thread, plus one for a manager thread, so that explains the extra
process you see.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --


_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list