Re: [Boost-users] [multi-index] Segmentation fault during erase

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
popAvailableCall).
2. Is m_call used in a multi-threaded environment? If so, have you 
checked for synchronization
problems?
3. You might try setting the invariant-checking mode and safe mode 
described at
http://tinyurl.com/4o8jex 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