lua-users home
lua-l archive

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

Sadly, none of these can be the issue, as the very same module works or does
not work depending on which driver program calls it.  The basic approach must
be sound or else gc would never occur.

I also set a panic function just to be sure.  It was not called.

On Wed, Jul 16, 2008 at 11:49:51AM -0400, Matthew Paul Del Buono wrote:
> Unfortunately I'm at an airport right now and don't have time to fully look into what's going on (maybe I can in a few hours :) ), but I can give you a general tip which tends to be the problem here:
> Are you using light userdata? If so, keep in mind that Lua never GCs a light userdata object. As a result, your __gc metamethod will never be called. 
> If you're using full userdata, double-check that the GC never encounters an error. The easiest way to do this is probably to set lua_atpanic to something easily noticeable, like a message box popup. In most cases, you should get an error whether or not the GC encounters an error, but I have found a few cases where I really screwed around with things and I was just getting systems to quit without any real notice whatsoever.
> If you are using light userdata, though, that's going to be your problem. You have a few options -- the easiest would be to create a full userdata which allocates just enough space for the pointer, and then store data there, though this is slightly more expensive. The other is to watch these userdata on your own, which, while more difficult, may produce better results.
> Hopefully I can review your code and give you a better explanation in the near future :)
> -- Matthew P. Del Buono
> ---- Original message ----
> >Date: Tue, 15 Jul 2008 22:34:19 -0700
> >From: Chip Salzenberg <>  
> >Subject: Help with GC (with xstring 1.0.1)  
> >To:
> >
> >On Tue, Jul 15, 2008 at 11:23:16AM -0700, Chip Salzenberg wrote:
> >>
> >
> >I've go a weirdness with GC that I'm having a bit of difficulting tracking
> >down.  The xstring module comes with two programs that, from a structural
> >POV, do the same thing: create a Lua state, load a Lua file that defines a
> >function, create some xstrings, and pass the xstrings to the Lua function.
> >
> >Here's the weirdness: the testxs program's xstrings get their __gc functions
> >called, so it has no memory leaks; but the xsperf program's xstrings do
> >*not* get their __gc functions called, so it *does* have memory leaks.  Note
> >that I'm calling lua_close() in both cases, so in both cases all extant
> >userdata should *eventually* be finalized.  But in one case, it isn't.
> >
> >Even speculation would be welcome (though reading the code too would be nice
> >:-)); what could I doing differently such that I could interfere with GC at
> >lua_close()?
> >
> >PS: xsperf has a couple of memory leaks unrelated to GC that I've fixed in
> >    my working copy; the mystery at this point is all about __gc.
> >-- 
> >Chip Salzenberg <>

Chip Salzenberg <>