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. Kind regards, Samuel