[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: Lua 5.0 beta/loadmodule question
- From: "Brett Kapilik" <brett@...>
- Date: Mon, 10 Mar 2003 15:55:33 -0600
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)
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?
> -----Original Message-----
> From: Wim Couwenberg [mailto:firstname.lastname@example.org]
> Sent: Monday, March 10, 2003 3:24 PM
> To: Multiple recipients of list
> Subject: Re: Lua 5.0 beta/loadmodule question
> > 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...