Re: double deletion problem with shared pointers.

Nigel Atkinson wrote:
> On Thu, 2009-11-26 at 11:00 +0100, Daniel Wallin wrote:
>   
>> Nigel Atkinson wrote:
>>     
>>> The attached code shows the double deletion problem I encounted.  I
>>> previously thought that the problem only surfaced when using the
>>> shared_ptr_converter.  However it looks like it happens either way.
>>>       
>> Right. This fails because the widget_wrapper instance that corresponds
>> to your Lua widget instance is held in a global shared_ptr, which is
>> destructed after the Lua state is destroyed.
>>
>> widget_wrapper will hold a weak back reference to the Lua instance, so
>> that it can call back to overridden functions in Lua. When it is
>> destructed it will clean up the weak reference, and in this case that
>> means accessing a destroyed Lua state.
>>
>> shared_ptr_converter has the same problem. It stores a back reference to
>> the Lua instance, keeping it alive so that you don't get the slicing you
>> encountered, and when it's destructed it cleans that up.
>>
>> AFAIK there's really no way around this. You need to ensure that you
>> don't destroy the Lua state while you still have references to Lua
>> objects around.
>>
>>     
> If I use intrusive pointers, that is, the ref count is with the object
> rather than the individual pointer, it should work.  Pointers made from
> a raw pointer have the correct ref count.  However I've hit a problem of
> the luaRef that keeps the object from slicing, also keeps the ref count
> up by one, and it is indistinguishable from other (none or more)
> references to the object.  It like I need some sort of ref counting in
> the Lua code too. 
>
> So close!
>
> The other option would be to get a copy of the global shared pointer
> that holds the widget_wrapper, and store that.
>
> Of course the easiest way for my current problem would be to just store
> the list of widget children in Lua.
>
> Thank you for your help Daniel, and Evan, much appreciated. And everyone
> else too.
>
> Nigel
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> luabind-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/luabind-user
>
>   

Maybe it's just me, but the phrase "global shared pointer" deeply 
concerns me. If you need to keep a global pointer to something that 
shares ownership, it should be a global *weak* pointer, not shared 
pointer. That way, if everyone but the global scope destroys their 
pointer, then the global pointer is properly destroyed too. Unless you 
actually want the lifetime of the pointer to be global, it really ought 
to be a weak pointer.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july