lua-users home
lua-l archive

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


I have not tried the DLL thing yet.  However, I hace been looking more at the problem and I think that I have a handle on it a bit more.  My application statically links the MFC libraries.  This means that it links with the static version of the C runtime library.  This means that my app keeps a different heap for itself that is seperate from the one that the extension DLL uses.

That is the problem.  So for example, if I have a function in my extension DLL like so:

static int testlib_sayhi (lua_State *L)
{
	MessageBox(NULL,"Hi","1",MB_OK);

	char szHi[10];

	lstrcpy(szHi,"Hello");

	lua_pushstring(L, szHi);

	return 1;
}

it also causes the same problem.  In the function above, lua_pushstring ultimately calls the C runtime function realloc which creates the string on the DLL's heap.  Then when my application exits and calls lua_close, lua_close causes the assertion because it is trying to free memory from my application that was allocated from the extension DLL.  Does that make sense?

I think my solution is to go into "lmem.c" and re-write the luaM_realloc function to use GlobalAlloc and GlobalFree in order to share the heap between the DLL and the application.  Has anyone ever done that before?  Any other ideas?

Regards,

Brett

> -----Original Message-----
> From: Wim Couwenberg [mailto:w.couwenberg@chello.nl]
> Sent: Monday, March 10, 2003 3:24 PM
> To: Multiple recipients of list
> Subject: Re: Lua 5.0 beta/loadmodule question
> 
> 
> Hi,
> 
> > MyApplication - Includes the lua .h files and lua.lib and luaD.lib
> > ExtensionDLL - Includes the lua .h files and lua.lib and 
> luaD.lib - this is the extension library loaded using loadmodule.c
> 
> Do I understand correctly that both your app and extesion
> link against the static lua libs?  Then two incarnations of
> the lua environment exist in the same process and that
> doesn't sound promising...  Did you try linking both your
> app and the extension against a dynamic lua lib, so lua gets
> pulled in (from the lua.dll) only once?
> 
> It is safest to build a lua.dll from your own project,
> because mixing prebuild binaries can be a problem in itself
> (as reported earlier on this list.)  Make sure that a
> dynamic version of the runtime lib is used everywhere...
> 
> Bye,
> Wim
> 
>