segfault in ServantManager

n2503vn2503v Member Alex MakarenkoOrganization: ACFR, University of SydneyProject: Orca ✭✭✭
Hello,

I have a fairly complicated application with 1 communicator, 1 adapter, and several servants. Through one of the servants the app may be told to restart. When this happens it calls Communicator::shutdown() which is supposed to lead to an orderly shutdown of the app.

Instead I get a segfault with a trace shown below. As far as I can tell, by the time this segfault happens the Communicator is shutdown, and the Adapter is deactivated.

I realize that it may not be easy for you to comment on this without a simple example but I'm hoping you can easily say what the ServantManager is trying to do at this point. Then I can dig deeper into my code.

Cheers,
Alex

Ice-3.4.1, C++, Linux.
(gdb) where
#0  0xb7e60e9c in IceInternal::upCast (p=0x80c4040) at Object.cpp:22
#1  0x08065887 in IceInternal::Handle<Ice::Object>::~Handle() ()
#2  0xb7e03450 in ~pair (this=0x80c4098, __in_chrg=<value optimized out>) at /usr/include/c++/4.4/bits/stl_pair.h:68
#3  0xb7e0840b in __gnu_cxx::new_allocator<std::pair<std::string const, IceInternal::Handle<Ice::Object> > >::destroy (this=0xbfffe63f, __p=0x80c4098)
    at /usr/include/c++/4.4/ext/new_allocator.h:115
#4  0xb7e07066 in std::_Rb_tree<std::string, std::pair<std::string const, IceInternal::Handle<Ice::Object> >, std::_Select1st<std::pair<std::string const, IceInternal::Handle<Ice::Object> > >, std::less<std::string>, std::allocator<std::pair<std::string const, IceInternal::Handle<Ice::Object> > > >::_M_destroy_node (this=0x80c41e0, 
    __p=0x80c4088) at /usr/include/c++/4.4/bits/stl_tree.h:383
#5  0xb7e05f98 in std::_Rb_tree<std::string, std::pair<std::string const, IceInternal::Handle<Ice::Object> >, std::_Select1st<std::pair<std::string const, IceInternal::Handle<Ice::Object> > >, std::less<std::string>, std::allocator<std::pair<std::string const, IceInternal::Handle<Ice::Object> > > >::_M_erase (this=0x80c41e0, 
    __x=0x80c4088) at /usr/include/c++/4.4/bits/stl_tree.h:972
#6  0xb7e04356 in ~_Rb_tree (this=0x80c41e0, __in_chrg=<value optimized out>) at /usr/include/c++/4.4/bits/stl_tree.h:614
#7  0xb7e03427 in ~map (this=0x80c41e0, __in_chrg=<value optimized out>) at /usr/include/c++/4.4/bits/stl_map.h:87
#8  0xb7ecec4a in ~pair (this=0x80c41d8, __in_chrg=<value optimized out>) at /usr/include/c++/4.4/bits/stl_pair.h:68
#9  0xb7ed1817 in __gnu_cxx::new_allocator<std::pair<Ice::Identity const, std::map<std::string, IceInternal::Handle<Ice::Object>, std::less<std::string>, std::allocator<std::pair<std::string const, IceInternal::Handle<Ice::Object> > > > > >::destroy (this=0xbfffe74f, __p=0x80c41d8) at /usr/include/c++/4.4/ext/new_allocator.h:115
#10 0xb7ed0d3a in std::_Rb_tree<Ice::Identity, std::pair<Ice::Identity const, std::map<std::string, IceInternal::Handle<Ice::Object>, std::less<std::string>, std::allocator<std::pair<std::string const, IceInternal::Handle<Ice::Object> > > > >, std::_Select1st<std::pair<Ice::Identity const, std::map<std::string, IceInternal::Handle<Ice::Object>, std::less<std::string>, std::allocator<std::pair<std::string const, IceInternal::Handle<Ice::Object> > > > > >, std::less<Ice::Identity>, std::allocator<std::pair<Ice::Identity const, std::map<std::string, IceInternal::Handle<Ice::Object>, std::less<std::string>, std::allocator<std::pair<std::string const, IceInternal::Handle<Ice::Object> > > > > > >::_M_destroy_node (this=0xbfffe918, __p=0x80c41c8) at /usr/include/c++/4.4/bits/stl_tree.h:383
#11 0xb7ed0168 in std::_Rb_tree<Ice::Identity, std::pair<Ice::Identity const, std::map<std::string, IceInternal::Handle<Ice::Object>, std::less<std::string>, std::allocator<std::pair<std::string const, IceInternal::Handle<Ice::Object> > > > >, std::_Select1st<std::pair<Ice::Identity const, std::map<std::string, IceInternal::Handle<Ice::Object>, std::less<std::string>, std::allocator<std::pair<std::string const, IceInternal::Handle<Ice::Object> > > > > >, std::less<Ice::Identity>, std::allocator<std::pair<Ice::Identity const, std::map<std::string, IceInternal::Handle<Ice::Object>, std::less<std::string>, std::allocator<std::pair<std::string const, IceInternal::Handle<Ice::Object> > > > > > >::_M_erase (this=0xbfffe918, __x=0x80c41c8) at /usr/include/c++/4.4/bits/stl_tree.h:972
#12 0xb7ed0148 in std::_Rb_tree<Ice::Identity, std::pair<Ice::Identity const, std::map<std::string, IceInternal::Handle<Ice::Object>, std::less<std::string>, std::allocator<std::pair<std::string const, IceInternal::Handle<Ice::Object> > > > >, std::_Select1st<std::pair<Ice::Identity const, std::map<std::string, IceInternal::Handle<Ice::Object>, std::less<std::string>, std::allocator<std::pair<std::string const, IceInternal::Handle<Ice::Object> > > > > >, std::less<Ice::Identity>, std::allocator<std::pair<Ice::Identity const, std::map<std::string, IceInternal::Handle<Ice::Object>, std::less<std::string>, std::allocator<std::pair<std::string const, IceInternal::Handle<Ice::Object> > > > > > >::_M_erase (this=0xbfffe918, __x=0x80c3fe8) at /usr/include/c++/4.4/bits/stl_tree.h:970
#13 0xb7ed0807 in std::_Rb_tree<Ice::Identity, std::pair<Ice::Identity const, std::map<std::string, IceInternal::Handle<Ice::Object>, std::less<std::string>, std::allocator<std::pair<std::string const, IceInternal::Handle<Ice::Object> > > > >, std::_Select1st<std::pair<Ice::Identity const, std::map<std::string, IceInternal::Handle<Ice::Object>, std::less<std::string>, std::allocator<std::pair<std::string const, IceInternal::Handle<Ice::Object> > > > > >, std::less<Ice::Identity>, std::allocator<std::pair<Ice::Identity const, std::map<std::string, IceInternal::Handle<Ice::Object>, std::less<std::string>, std::allocator<std::pair<std::string const, IceInternal::Handle<Ice::Object> > > > > > >::clear (this=0xbfffe918) at /usr/include/c++/4.4/bits/stl_tree.h:726
#14 0xb7ecf40b in std::map<Ice::Identity, std::map<std::string, IceInternal::Handle<Ice::Object>, std::less<std::string>, std::allocator<std::pair<std::string const, IceInternal::Handle<Ice::Object> > > >, std::less<Ice::Identity>, std::allocator<std::pair<Ice::Identity const, std::map<std::string, IceInternal::Handle<Ice::Object>, std::less<std::string>, std::allocator<std::pair<std::string const, IceInternal::Handle<Ice::Object> > > > > > >::clear (this=0xbfffe918)
    at /usr/include/c++/4.4/bits/stl_map.h:626
#15 0xb7eceb32 in IceInternal::ServantManager::destroy (this=0x80b9ff8) at ServantManager.cpp:488
---Type <return> to continue, or q <return> to quit---
#16 0xb7e4dab5 in Ice::ObjectAdapterI::destroy (this=0x80b9b00) at ObjectAdapterI.cpp:370
#17 0xb7e4bc87 in IceUtilInternal::VoidMemFun<Ice::ObjectAdapter, IceUtil::Handle<Ice::ObjectAdapter> >::operator() (this=0xbfffea1c, handle=...)
    at ../../include/IceUtil/Functional.h:65
#18 0xb7e4b158 in std::for_each<std::_List_iterator<IceUtil::Handle<Ice::ObjectAdapterI> >, IceUtilInternal::VoidMemFun<Ice::ObjectAdapter, IceUtil::Handle<Ice::ObjectAdapter> > > (__first=..., __last=..., __f=...) at /usr/include/c++/4.4/bits/stl_algo.h:4200
#19 0xb7e49c60 in IceInternal::ObjectAdapterFactory::destroy (this=0x80b6ad0) at ObjectAdapterFactory.cpp:105
#20 0xb7e025cd in IceInternal::Instance::destroy (this=0x80b6758) at Instance.cpp:1229
#21 0xb7d948a7 in Ice::CommunicatorI::destroy (this=0x80b6718) at CommunicatorI.cpp:104
#22 0xb7d76149 in Ice::Application::doMain (this=0xbffff0d8, argc=2, argv=0xbffff1d4, initializationData=...) at Application.cpp:717
#23 0xb7d74aa2 in Ice::Application::main (this=0xbffff0d8, argc=2, argv=0xbffff1d4, initData=...) at Application.cpp:387
#24 0xb6f0d93f in orcaice::Application::orcaMain (this=0xbffff0d8, argc=2, argv=0xbffff1d4, dispatcher=0x0)
    at /home/makara/svn/mrsrc-10.10/orca/src/libs/orcaice/application.cpp:116
#25 0x080851af in main (argc=2, argv=0xbffff1d4) at /home/makara/svn/mrsrc-10.10/build/mr/src/components/sysadmin/autogen/main.cpp:23

Comments

  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi,

    The SEGFAULT occurs when the object adapter is clearing the active servant map. It sounds like a memory management issue. You could try using valgrind to debug this.

    Cheers,
    Benoit.
Sign In or Register to comment.