Re: [Boost-users] Am I doing something wrong here? Boost threads & intrusive_ptr crash

Subject: Re: [Boost-users] Am I doing something wrong here? Boost threads & intrusive_ptr crash
From: Nigel Rantor (wiggly_at_[hidden])
Date: 2009-06-11 12:15:44

Space Ship Traveller wrote:
> 
> On 12/06/2009, at 2:37 AM, Nigel Rantor wrote:
> 
>> Space Ship Traveller wrote:
>>> Hi,
>> [snip]
>>> Here is the function which is used to post a notification. REF(t) is
>>> simply a macro for boost::intrusive_ptr<t>.
>>
>> Can you confirm which of the following REF(INotificationSource) maps to?
>>
>> boost::intrusive_ptr<INotificationSource> note
> 
> This one.
> 
>>
>> or
>>
>> boost::intrusive_ptr<INotificationSource>& note
>>
> 
> Sometimes I use this form, but not in this case.
> 
>> More concretely, is the parameter:
>>
>> 1 - a reference to an already existing intrusive_ptr
>>
>> 2 - a new intrusive_ptr using a copy constructor
>>
>> 3 - a new intrusive_ptr accepting a raw pointer
>>
>> If it is the third one then there is nothing to stop some particular
>> interleaving of instructions decrementing the ref count to zero between
>> your check and the construction of the parameter.
>>
>> Whether or not this causes an obvious error when you attempt to create a
>> new intrusive_ptr from it will depend a lot of things.
>>
>> For example, I have a test I just made and I can get this to fail hard
>> and to simply create a new intrusive_ptr from an invalid pointer,
>> depending on what I do....
> 
> I appreciate your insight into the situation. I'm currently reviewing
> the code, but there is definitely some bug like this.
> 
> I think it is a case of an increment and decrement interleaving in such
> a way that the increment never occurs, and thus the object is freed even
> thought there is still a reference to it.

As Steven pointed out if the inc/dec code is not thread-safe then the
case I pointed out is just one more way it can fail.

Happy to look at more code, especially if you can create a minimal
failing case...

  n