Boost logo

Boost Users :

Subject: Re: [Boost-users] [multi-index] Segmentation fault during erase
From: joaquin_at_[hidden]
Date: 2008-10-09 02:18:47

Joshua Moore-Oliva escribió:
> (I am using 64-bit boost 1.33.1, gcc version 4.1.2)
> I am trying to track down an elusive segmentation fault that occurs after days
> of running a program. I am wondering if I am using the boost multi-index
> library incorrectly. I have a coredump that gives the following backtrace
> (full backtrace at the end of this email).
> at /usr/include/boost/multi_index/detail/ord_index_node.hpp:274
> a274 while(x!=root&&(x==0 || x->color()==black)){
> having looked at the code in that function, I can only assume it is called as
> a result of these two following lines: (Attempting to erase the first member
> of the index).
> CallQueue::nth_index<CALL_NEXT_CALL_TIME>::type & timeIndex =
> this->m_calls.get<CALL_NEXT_CALL_TIME>();
> timeIndex.erase( timeIndex.begin() );
> I am certain that the queue is not empty, as the following methods guard
> against an empty queue. (Shown in an excerpt of my relevant code at the
> bottom of this email).
> Finally, my definition for the m_calls structure and #defines for the indexes
> follow at the end of this email. My program is very clean memory wise,
> having run a fairly extensive test suite through valgrind, so the possibility
> of other memory errors compounding are low. My main question is if I am
> using the multi-index library incorrectly, or if there is a bug in the
> multi-index library. Failing that, any insight as to why I would be getting
> this error is appreciated :).
> Thanks, Josh

Hello Josh, I don't see anything patently suspicious in the code you
provide. You might want to
check the following issues:

1. m_calls is a multi_index_container of Call *pointers*. Is it possible
that a Call is deleted *before*
its pointer is erased from m_call? This could trigger problems like the
one you're seeing, in contexts
removed from the point where the Call object is deleted (as could be the
case here with
2. Is m_call used in a multi-threaded environment? If so, have you
checked for synchronization
3. You might try setting the invariant-checking mode and safe mode
described at and see whether this sheds some further light.
Be aware that these modes
have a huge impact on performance and should be used only in debug builds.

Looking fwd to your feedback,

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at