Archived

This forum has been archived. Please start a new discussion on GitHub.

Segmentation fault with Freeze

Ice:3.1.0 on Linux
===============
the call stack backtrace are:
operator new(unsigned long)
__gnu_cxx::new_allocator<Freeze::EvictorI::StreamedObject>::allocate(unsigned long, void const*)
std::_Deque_base<Freeze::EvictorI::StreamedObject, std::allocator<Freeze::EvictorI::StreamedObject> >::_M_allocate_node()
std::_Deque_base<Freeze::EvictorI::StreamedObject, std::allocator<Freeze::EvictorI::StreamedObject> >::_M_create_nodes(Free
ze::EvictorI::StreamedObject**, Freeze::EvictorI::StreamedObject**)
std::_Deque_base<Freeze::EvictorI::StreamedObject, std::allocator<Freeze::EvictorI::StreamedObject> >::_M_initialize_map(un
signed long)
std::_Deque_base<Freeze::EvictorI::StreamedObject, std::allocator<Freeze::EvictorI::StreamedObject> >::_Deque_base(std::all
ocator<Freeze::EvictorI::StreamedObject> const&, unsigned long)
std::deque<Freeze::EvictorI::StreamedObject, std::allocator<Freeze::EvictorI::StreamedObject> >::deque(std::allocator<Freez
e::EvictorI::StreamedObject> const&)
Freeze::EvictorI::run()
__clone2

and after the first segment fault, another segment fault occured,here are backtraces also:
__libc_free
operator delete(void*)
__gnu_cxx::new_allocator<IceInternal::Handle<IceInternal::EndpointI> >::deallocate(IceInternal::Handle<IceInternal::Endpoin
tI>*, unsigned long)
std::_Vector_base<IceInternal::Handle<IceInternal::EndpointI>, std::allocator<IceInternal::Handle<IceInternal::EndpointI> >
 >::_M_deallocate(IceInternal::Handle<IceInternal::EndpointI>*, unsigned long)
std::_Vector_base<IceInternal::Handle<IceInternal::EndpointI>, std::allocator<IceInternal::Handle<IceInternal::EndpointI> >
 >::~_Vector_base()
std::vector<IceInternal::Handle<IceInternal::EndpointI>, std::allocator<IceInternal::Handle<IceInternal::EndpointI> > >::~v
ector()
IceInternal::DirectReference::~DirectReference()
IceInternal::decRef(IceInternal::Reference*)
IceInternal::Incoming::invoke(IceInternal::Handle<IceInternal::ServantManager> const&)
Ice::ConnectionI::invokeAll(IceInternal::BasicStream&, int, int, unsigned char, IceInternal::Handle<IceInternal::ServantMan
ager> const&, IceInternal::Handle<Ice::ObjectAdapter> const&)
Ice::ConnectionI::message(IceInternal::BasicStream&, IceInternal::Handle<IceInternal::ThreadPool> const&)
IceInternal::ThreadPool::run()
IceInternal::ThreadPool::EventHandlerThread::run()
__clone2

This phenomenon was found only once, because I install a signal handler for [segment fault] signals, after the segment fault occured,the process didn't exit but hanged. I am very confused about that. Would you please give some advice?

Thanks a lot.

Comments

  • matthew
    matthew NL, Canada
    From this information its pretty hard to tell what exactly is going on other than you have gotten some sort of memory corruption. You might want to try running with some memory corruption tool such as purify, or perhaps valgrind. You could also attach gdb to the application at startup and then catch the segfault when it occurs and check out the state of memory and threads.

    Since this is occuring with Freeze perhaps you are not synchronizing correctly? Are you following the advice in the Freeze chapter (ie: inheriting from IceUtil::AbstractMutex, etc) and ensuring that you protect state correctly in the servant?
  • matthew wrote: »
    From this information its pretty hard to tell what exactly is going on other than you have gotten some sort of memory corruption. You might want to try running with some memory corruption tool such as purify, or perhaps valgrind. You could also attach gdb to the application at startup and then catch the segfault when it occurs and check out the state of memory and threads.

    Since this is occuring with Freeze perhaps you are not synchronizing correctly? Are you following the advice in the Freeze chapter (ie: inheriting from IceUtil::AbstractMutex, etc) and ensuring that you protect state correctly in the servant?
    All my servants have inherited IceUtil::AbstractMutex, I'll recheck my codes.Thank you!