Re: [Boost-users] [smart_ptr] Getting segfaults withweak_ptr<T>::lock()

From: Buddha Buck (blaisepascal_at_[hidden])
Date: 2007-07-12 22:22:45

On 7/11/07, Peter Dimov <pdimov_at_[hidden]> wrote:
>
> Very odd address space layout; the shared_ptr code at 0x00002b3ba3bcb6ff and
> the shared_count/sp_counted_base code at 0x000000000041c711. The 'this'
> pointer for the sp_counted_base object - 0x2b3ba59cdae0 - seems suspicious,
> too close to code, too far from the this pointer for the weak_ptr
> (0x70f4a70) which should also be on the heap. Hard to say where things go
> wrong. Can you post the assembly around the faulting location? Might it be
> possible for the two code segments, 2b3ba3.. and 41c.., to be coming from
> two separate versions of Boost?

I found the problem, and it is such a stupid cause I hesitate to
mention it here for fear of looking foolish.

If you recall, my notifyObservers() function looked like:

void Observed::notifyObservers()
{
  vector<weak_ptr<Observer> >::iterator i;
  for (i = _observers.begin(); i != _observers.end(); observer++)
  {
    shared_ptr<Observer> o = i->lock();
    if (o) o->update(shared_from_this());
  }
}

What I didn't realize at the time was that one of the actions an
observer could (and indeed, does) do is to create new observers for
the observed object.  The practical result being that while in the
loop, the vector _observers could (and indeed was) modified, yielding
the possibility of an invalid iterator.

It's not an issue with boost at all, but a problem where I didn't
respect the limitations of std::vector<>.  I'm sorry to have bothered
you with a simple case of PEBKAC.