Re: Luabind and boost::shared_ptr<T> use counts

On 02/06/10 03:33, Jason McKesson wrote:
> On 6/1/2010 6:32 AM, Patrick Hartling wrote:
>    
>> On Jun 1, 2010, at 1:04 AM, Jason McKesson wrote:
>>
>>
>>      
>>> On 5/31/2010 2:34 PM, Patrick Hartling wrote:
>>>
>>>        
>>>> I am trying to understand how Luabind handles boost::shared_ptr<T>    objects. Specifically, the use count for any boost::shared_ptr<T>    passed to a Lua function is incremented during the function execution but not decremented once the function call completes. This leads to memory leaks if there is an expectation of the use count on these objects eventually reaching zero.
>>>>
>>>> The attached program demonstrates what I am seeing. If the shared pointer-wrapped object is wrapped in boost::ref() before being passed to Luabind (see line 72), then the use count works out correctly. Is this the correct way to use boost::shared_ptr<T>    with Luabind, or is there a preferred practice? In general, I think it will be fine use to use boost::ref() as long as we are careful.
>>>>
>>>> I tested with Luabind 0.8.1, Boost 1.43, and Lua 5.1.4 on Mac OS X 10.6. The same behavior occurs on Linux.
>>>>
>>>>    -Patrick
>>>>
>>>>
>>>> --
>>>> Patrick L. Hartling
>>>> Senior Software Engineer, Priority 5
>>>> http://www.priority5.com/
>>>>
>>>>
>>>>          
>>> Lua is a garbage collected system. The reference will not disappear
>>> until Lua does garbage collection and actually deallocates the memory
>>> associated with the shared pointer. Since GC is a costly operation, Lua
>>> does not constantly sweep and delete from memory. Thus there is no
>>> guarantee that an object will be deleted immediately.
>>>
>>>        
>> Ah, of course. That makes perfect sense.
>>
>>
>>      
>>> Generally, you shouldn't worry about this. The object will eventually be
>>> deleted, even if it happens to sit around until the Lua state is destroyed.
>>>
>>>        
>> What we are seeing is that the objects are not being deleted even after several minutes of execution. We may have something much more insidious going wrong if garbage collection is not happening as expected.
>>
>>    -Patrick
>>
>>
>> --
>> Patrick L. Hartling
>> Senior Software Engineer, Priority 5
>> http://www.priority5.com/
>>
>>      
> Again, why would it be? If you're not using Lua to the point where it
> thinks it needs to GC the object, then it won't. At no time does Lua
> provide a timeframe guarantee on when memory will be GC'd.
>
> Lua only guarantees that it releases memory when you destroy the Lua
> state; otherwise it can hold on to a reference indefinitely, depending
> on how much you use the Lua state. After doing so, if you then still
> don't get the object's reference count being dropped, then there is a
> problem.
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> luabind-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/luabind-user
>    
If you want to make sure the memory is released, you can force a garbage 
collection iteration using 'collectgarbage()' from a script or lua_gc() 
from C/C++. Depending on the complexity of the object relationships, you 
may need to run several iterations. This really should be only done for 
debugging however - its better to leave the GC do it's own thing 
usually. Keep in mind also that the GC only runs when you run a script! :-)

Nigel

------------------------------------------------------------------------------