Re: tolua++ porting to 5.2

[Hadriel Kaplan <HKaplan@...>]

On Jan 14, 2013, at 4:59 PM, Ross Bencina <rossb-lists@audiomulch.com> wrote:

> On 15/01/2013 7:45 AM, Hadriel Kaplan wrote:
>> and had considered making all of our pushed C++ objects derive from a
>> common base that had a member variable for a 'serial number': a
>> number which is unique for every C++ object for all time.[**]  The
>> pushed object in Lua would have a copy of this serial number, and
>> would be checked against the C++ object's serial number on every
>> method call.
> 
> How do you handle the case where allocator causes the allocated page(s) to be unmapped? or do you ensure that the pages are never unmapped?

You mean and not segfault?  It wouldn't prevent that - I was only talking about the (hopefully rare) case when your Lua program is incorrectly accessing previously-free'd memory that is once again in use, so that it seems to actually *work* for a while and fail later.  That makes debugging the root cause very painful, especially since it's not necessarily reproducible, nor with the same symptoms.

I mean ultimately the Lua programmer screwed up - they kept a userdata pointing to a C object around when they shouldn't have.  Or you could say the C developer "screwed up" by having a design that lets that happen (ie, by freeing/deleting objects that could be being held in Lua). 

-hadriel