Luabind and boost::shared_ptr<T> use counts

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Luabind and boost::shared_ptr<T> use counts

Patrick Hartling
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/

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


_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user

lua_test.cpp (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Jason McKesson
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.

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.

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

_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user
Reply | Threaded
Open this post in threaded view
|

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

Patrick Hartling
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/


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

_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user
Reply | Threaded
Open this post in threaded view
|

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

Jason McKesson
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user
Reply | Threaded
Open this post in threaded view
|

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

Nigel Atkinson-2
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
> [hidden email]
> 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

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

_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user