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!
