lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 12/12/2011 8:58 PM, Drakkor . wrote:
The first pass through Foo, SMBuilder would allocate a new SMBuilderState at address X.  ToLua's generated code created a new usertype, putting the userdata block in its internal tolua_ubox table with address X as the key.  Once builder:delete is called, that address X is invalid, but the toLua generated code does not release the SMBuilderState usertype, it remains in tolua_ubox (uh oh!).
The second pass through Foo, toLua generated code ConvertEnumToUint32 allocates a new uint32_t at address X (that's fine, that block was freed when SMBuilder was deleted in the first pass).  toLua then pushes a new usertype onto the stack, again using the address X as a key in the tolua_ubox table, but wait, there is already an entry under that key!  Also, toLua specifies a special finalizer for this uint32_t using the tolua_clone function.  This function is added to a table (tolua_gc) with the address X as a key.  Here's where the fun begins! 

You're not doing anything wrong. tolua is profoundly broken in the way that you describe. I recommend against anyone using tolua for that reason.