RE: Lua 5.0 beta/loadmodule question

["Bilyk, Alex" <ABilyk@...>]

If you didn't modify lua_State in any way, than your problem is somewhere else. But, boy, does it look alike to what I had had. As to 'CommonHeader', if you look at lua_State structure you will notice that it begins with 'CommonHeader' macro. There is a number of other structures that begin with the same macro. This macro defines data for GC object links and *must* be the first field in any of such structures.

Alex

> -----Original Message-----
> From: Brett Kapilik [mailto:brett@indigorose.com]
> Sent: Thursday, March 06, 2003 10:40 AM
> To: Multiple recipients of list
> Subject: RE: Lua 5.0 beta/loadmodule question
> 
> 
> Thanks for the response.  I am using VC++ 6.0, so I don't 
> really know what you mean by, "GC relies on 'CommonHeader' 
> being the very first 'member' of any structure it is used 
> in."  Can you explain this?
> 
> I too have a C++ class that manages LUA within my app.  The 
> top of the class looks like this:
> 
> class CLUAEngine  
> {
> public:
> 	CLUAEngine();
> 	virtual ~CLUAEngine();
> 
> 	lua_State* m_pLUA;
> 
> 	... more variables and functions
> }
> 
> The first line of my constructor looks like this:
> 
> CLUAEngine::CLUAEngine()
> {
> 	m_pLUA = lua_open();
> 
> 	.. etc...
> }
> 
> My destructor looks like this:
> 
> CLUAEngine::~CLUAEngine()
> {
> 	lua_close(m_pLUA);
> }
> 
> Again, let me re-iterate that I never have any problems if I 
> don't call "module.load" from loadmodule.c.  If I do call it, 
> the loaded module works as expected but then I get the crash 
> at the end.  Any additional insights would be fantastic.
> 
> - Brett Kapilik
> 
> > -----Original Message-----
> > From: Bilyk, Alex [mailto:ABilyk@maxis.com]
> > Sent: Thursday, March 06, 2003 12:33 PM
> > To: Multiple recipients of list
> > Subject: RE: Lua 5.0 beta/loadmodule question
> > 
> > 
> > If my memory doesn't betray me, similar thing has happened to 
> > me. I was wrapping Lua API in a C++ class and added another 
> > member to lua_State as the very first member of that 
> > structure (just like I did in Lua 4). The app ran fine but 
> > would crash on exit in what seems to be the same piece of 
> > code. It occurred that GC relies on 'CommonHeader' being the 
> > very first 'member' of any structure it is used in. If not, 
> > GC would crash under most conditions.
> > 
> > AB
> > 
> > > -----Original Message-----
> > > From: Brett Kapilik [mailto:brett@indigorose.com]
> > > Sent: Thursday, March 06, 2003 8:22 AM
> > > To: Multiple recipients of list
> > > Subject: Lua 5.0 beta/loadmodule question
> > > 
> > > 
> > > This is a bit of a long shot, but I thought some of you Lua 
> > > gurus might be able to help...
> > > 
> > > I am using Lua 5.0 beta in a Win32 app (MFC).  I have been 
> > > using it for months with no troubles.  However, I want to add 
> > > loadmodule (the 12-18-2002 version from castanyo@yahoo.es) to 
> > > the project.  After a bit of manipulation to make 
> > > loadmodule.c to work in my project, I am pretty happy with 
> > > the results.  I can call module.load("MyModule") and it works 
> > > great.  I can call lua functions that get added from the DLL 
> > > as expected.
> > > 
> > > The problem is that if I call module.load during runtime, I 
> > > will always get an access violation when my application 
> > > exits.  The access violation occurs here (ltable.c):
> > > 
> > > /*
> > > ** search function for strings
> > > */
> > > const TObject *luaH_getstr (Table *t, TString *key) {
> > >   Node *n = hashstr(t, key);
> > >   do {  /* check whether `key' is somewhere in the chain */
> > > >>>> THIS LINE >>>>    if (ttisstring(key(n)) && 
> > > tsvalue(key(n)) == key)
> > >       return val(n);  /* that's it */
> > >     else n = n->next;
> > >   } while (n);
> > >   return &luaO_nilobject;
> > > }
> > > 
> > > Here is the call stack:
> > > 
> > > 
> > > 
> > 
> 
>