Hi Karel,
Thanks for the response. I plan on using newer versions of gcc on the
cluster in the future. (Unfortunately, the default compiler version on
the Linux clusters is gcc 3.3.3.) I'm trying 3.3.6 now since I noticed
that they added initialization code to the STL List Iterator:
http://gcc.gnu.org/viewcvs/branches/gcc-3_3-branch/libstdc%2B%2B-v3/include/bits/stl_list.h?view=log
I've also noticed some odd behavior in function pointers where the
address was set to 0xf0 or 0x10 instead of 0x0 for null. This may be
fixed, like you mentioned, by newer versions of gcc as well.
Thanks!
Rob
Karel Gardas wrote:
Hi,
I would personally strongly recommend you to try to use more recent
GCC compiler. For your information, we've used recent GCC 3.4.x/4.0.x
and 4.1.x on AMD64/Linux platform without any issue. Please report if
the issue persists even while using some of these compilers.
Cheers,
Karel
PS: Personally I'm using 4.1.x for MICO development.
On Tue, 2 Jan 2007, Rob Ratcliff wrote:
Hi ,
I've been getting a segmentation fault in the latest version of MICO
in the check_idle() method defined in iiop.cc.
It looks like one of the nodes in the list are null, which causes a
seg fault when the size of the List is requested.
I compiled MICO with threads disabled using gcc 3.3.3 (see below for
details) on a 64 bit Linux box. The detailed stack trace is shown
below as well.
Has anybody else seen this behavior. This fatal error only happens
intermittently (like every couple of days) so it is hard to debug.
Thanks,
Rob
#0 0x0000002a95fcf25b in std::_List_iterator_base::_M_incr
(this=0x7fbfff1558) at stl_list.h:116
116 { _M_node = _M_node->_M_next; }
#0 0x0000002a95fcf25b in std::_List_iterator_base::_M_incr
(this=0x7fbfff1558) at stl_list.h:116
#1 0x0000002a968af9cd in std::_List_iterator<CORBA::Buffer*,
CORBA::Buffer* const&, CORBA::Buffer* const*>::operator++ (
this=0x7fbfff1558) at stl_list.h:177
#2 0x0000002a968af9a8 in
__distance<std::_List_iterator<CORBA::Buffer*, CORBA::Buffer* const&,
CORBA::Buffer* const*> > (__first=
{<std::_List_iterator_base> = {_M_node = 0x0}, <No data
fields>}, __last=
{<std::_List_iterator_base> = {_M_node = 0xad8aa0}, <No data
fields>}) at stl_iterator_base_funcs.h:82
#3 0x0000002a968af963 in
distance<std::_List_iterator<CORBA::Buffer*, CORBA::Buffer* const&,
CORBA::Buffer* const*> > (__first=
{<std::_List_iterator_base> = {_M_node = 0xb05ee0}, <No data
fields>}, __last=
{<std::_List_iterator_base> = {_M_node = 0xad8aa0}, <No data
fields>}) at stl_iterator_base_funcs.h:114
#4 0x0000002a968af8cb in std::list<CORBA::Buffer*,
std::allocator<CORBA::Buffer*> >::size (this=0x9b7070) at stl_list.h:632
#5 0x0000002a968a2b11 in MICO::GIOPConn::check_idle (this=0x9b7050)
at iop.cc:2972
#6 0x0000002a968a2cbb in MICO::GIOPConn::deref (this=0x9b7050, all=0
'\0') at iop.cc:3015
#7 0x0000002a968aa7ce in MICO::IIOPServer::deref_conn
(this=0x6a0960, conn=0x9b7050, all=0 '\0') at iop.cc:5302
#8 0x0000002a968aa561 in MICO::IIOPServer::del_invoke_orbid
(this=0x6a0960, rec=0x85ba50) at iop.cc:5241
#9 0x0000002a968ac3d3 in MICO::IIOPServer::handle_invoke_reply
(this=0x6a0960, id=0x84b380) at iop.cc:5779
#10 0x0000002a968ace90 in MICO::IIOPServer::notify (this=0x6a0960,
id=0x84b380, ev=Invoke) at iop.cc:6021
#11 0x0000002a9687c04e in CORBA::ORB::answer_invoke (this=0x6a3c30,
id=0x84b380, stat=InvokeOk, obj=0x0, req=0x7a8b00, ad=0)
at orb.cc:2909
#12 0x0000002a96975eaa in MICOPOA::POA_impl::answer_invoke
(this=0x6e5f10, id=0x84b380, obj=0x798b50, oreq=0x7a8b00, stat=InvokeOk)
at poa_impl.cc:4174
#13 0x0000002a96890612 in ~ServerRequest (this=0x81c840) at dsi.cc:109
#14 0x0000002a96976177 in release (o=0x81c840) at object.h:69
#15 0x0000002a96968bce in ~InvocationRecord (this=0x80f620) at
poa_impl.cc:1449
#16 0x0000002a96976177 in release (o=0x80f620) at object.h:69
_______________________________________________
Mico-devel mailing list
[email protected]
http://www.mico.org/mailman/listinfo/mico-devel
