[orbitcpp-list] Re: digging a deeper and deeper hole

[Phil D. <ph...@or...>]

Ronald Garcia wrote:
> 
> From: Ronald Garcia <rga...@pi...>
> 
> howdy all,
> 
>      did a little more delving into my bus error problems...things are
> getting just a touch out of control now.  I'm not quite sure if this
> is a compiler or an ORBit problem, but it's sure a problem...and in
> general I tend to assume it's not the compiler, but I digress...
> 
>      to review, the error happens in
>  PortableServer_POA_activate_object (poa.c:711)
> 
>      this is the line:
> 
> new_objid =  ORBit_POA_allocate_oid(obj,
>                 ORBIT_OBJECT_KEY(servant->_private)->class_info->class_name);
> 
> well, the problem seems to be the following:
> 'ORBIT_OBJECT_KEY(servant->_private)->class_info' gets set in
> POA_test_IntegerTest__init (integer-skels.c:225)
> 
>      this is the line:
> 
> ORBIT_OBJECT_KEY(((PortableServer_ServantBase *) servant)->
>   _private)->class_info = (PortableServer_ClassInfo *) & class_info;
> 
> class_info is a static object within the function.
> 
> it turns out that the value of servant->_private->class_info is
> getting changed before it is used in
> 'PortableServer_POA_activate_object'. Here's where things get scary.
> The following is a trace of where it happens:
> 
> (gdb) continue
> Continuing.
> Watchpoint 2: $2->class_info
> 
> Old value = (PortableServer_ClassInfo *) 0x217c0
> New value = (PortableServer_ClassInfo *) 0x217c1
> 0xef445b08 in _smalloc ()
> (gdb) backtrace
> #0  0xef445b08 in _smalloc ()
> #1  0xef445b38 in malloc ()
> #2  0xef4fb684 in __builtin_new (sz=16) at ./cp/new1.cc:84
> #3  0xef7757f8 in PortableServer::POA::POA (this=0x34850, o=0x38c30,
>     parent=0x0, release=true) at POA.cc:117
> #4  0xef7759b0 in PortableServer::POA::_duplicate (_obj=0x347b0) at POA.cc:152
> #5  0xef774448 in CORBA::ORB::resolve_initial_references (this=0x35b10,
> continue    str=0xef783830 "RootPOA") at ORB.cc:116
> #6  0xef775624 in PortableServer::ServantBase::_default_POA (this=0xefffef04)
>     at POA.cc:93
> #7  0x18320 in POA_test::IntegerTest::_this (this=0xefffeef8)
>     at integer-cpp-skels.cc:121
> #8  0x17668 in main (argc=1, argv=0xefffef9c) at server.cc:23
> (gdb) up
> 
> the line of consequence is in POA.cc:117, that being:
> _poaManager = new PortableServer::POAManager(pm);
> 
> at this point, i haven't the foggiest idea why '_smalloc' would modify
> one of my locations...anyone, anyone?
> 
> If I step through to PortableServer_POA_activate_object and class_info
> back to its old value, the program runs properly.
> 
> ron
> 



Hi Ron,

I didn't get very far debugging this. I did notice however that the
echo-server in the *orbit* tests directory works without sigbussing.
I've written a little orbitcpp equivalent of the echo server which works
on my linux box. Unfortunately I've had the solaris box taken away from
me now (sob) because they want to shut it down ready for the millenium.
(doh - no sense of priority etc...)

Get the tarball from

ftp://orbitcpp.sourceforge.net/pub/orbitcpp/echo.tgz

and unpack it in the ORBit-C++ tests directory. (I recommend you get a
new CVS fresh version of ORBit-C++)

then add the Makefile.ams to the configure.in so that you can cd to it
and build it.


This will probably sigbus in the same way, but I was hoping to be able
to tweak things so that it takes the same (working) approach as the
echo-server test in orbit.

\Good luck, and have a good xmas

Phil.

P.S. A brief look at the ORBit echo-server.c shows that it creates it's
own object id and uses that... Dunno if that makes a difference.