RE: Garbage Collector collecting the code as it executes?

[Greg Underwood <gunderwood@...>]

Matthew,

Thanks for taking the time to answer!  It does seem to be a pretty thorny problem, and I tried to boil it down as much as possible but it still came out pretty hefty - I needed moderator approval to get my first post posted due to the size!  :D

For your assessment - I understand what you mean - Lua should only ever have a string there or not, and if it's not a string, it should return NULL.  And I see what you mean about hanging onto a pointer to a Lua stack variable in C/C++ after Lua has finished with it - that would definitely be a problem as Lua wouldn't be able to see the reference and may well garbage collect it, resulting in C/C++ having a dangling reference to freed memory.

However, I don't think either of those are occurring here.  The string in question is a token out of the source code, and my functions are the metamethods being called as the source code is being processed.  So my code can't have seen the token prior to this call, which means there's no way I could be hanging onto a pointer to it.  And  - even if I was holding on to a pointer - this token hasn't been processed yet.  It seems to me that it shouldn't be freed by the GC until after we're done processing - EG: after the call to my metamethod.

Finally - In this case lua_tostring() seems to think it is returning a string - the value in method_name is a pointer to memory, not NULL, and the memory was, just prior to the GC run, a string that contains the next token to be processed - AddLight.  But because it's been GC'd, the string just has garbage in it.  It seems to me that this is the problem - lua_tostring() is, validly, going to return a string, but that string got incorrectly Garbage Collected.

My metamethod code apparently behaves correctly multiple times prior to the malfunction, and apparently behaves correctly when I structure the lua file differently - all the instructions inside a function instead of loose in the file.  It's possible there's a subtle error in my code, but the fact that it runs correctly until Lua's GC runs leads me to believe it's more likely a subtle bug in Lua's processing - Lua seems to be GC'ing a variable that Lua itself is still using.

Hopefully I'll get a little time to create a stand-alone sample that demonstrates the behavior.  (If nothing else that will give me a chance to try a few more things to convince myself that it is something in Lua and not something I've done - which I still don't have enough data to decide ;) ).  Until then, I was hoping someone with intimate knowledge of the GC and token processing routines would chime in (forgive me if you're that person!  I'm new here and don't know who knows what... ;) ) and help sort out what's going on.

Cheers!

-Greg


-----Original Message-----
From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On Behalf Of Matthew Wild
Sent: Thursday, December 01, 2011 10:30 PM
To: Lua mailing list
Subject: Re: Garbage Collector collecting the code as it executes?

Hi,

On 1 December 2011 01:00, Greg Underwood <gunderwood@fiercewombatgames.com> wrote:
> Forgive me if this has been discussed already, but I can’t find it
> after spending some time searching the archives.  If it has and you
> have a link, please just send me there!  :D
>

Obviously your problem is rather technical and your explanation long and naturally hard to follow which is probably why no-one has responded yet. But I'm going to make a start:

    method_name    = lua_tostring(lua_state, 2);

If you say that this is returning garbage because the string that should be at index 2 has been collected by the garbage collector, this is (hopefully) incorrect. Either there is a Lua value of type string (or number) at index 2, in which case Lua will give you a pointer to that string, or there is not, when Lua will return NULL. It never returns a pointer to garbage.

One way to end up with garbage would be to store the pointer in C after the string has been removed from the stack (then the garbage collector may indeed remove it).

Good luck,
Matthew


IMPORTANT: This email message is intended only for the use of the individual to whom, or entity to which, it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are NOT the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.  If you have received this communication in error, please reply to the sender immediately and permanently delete this email. Thank you.