lua-users home
lua-l archive

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


On Fri, Mar 19, 2010 at 12:01 PM, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:

I did not understand the relationship between the above code and the
description. You talk about a "sentinel data", but I did not find
where you are creating it in the code (it should be a full userdata
to have its __gc called).

Without seing the relevant code, I would say that the most probable
cause of your problem is that you are creating the sentinel data
*before* opening the library. "The finalizers for userdata are called in
reverse order of their creation" (ref manual, 2.10.1). So, if you
create the userdata before opening the library, the library will be
closed before the invocation of the __gc of that userdata.


Hi Roberto. Sorry, the last message came out very confusing. I've now simplified the code. It has nothing to do with the code I posted in the last message.
What I did now is this: two libraries, mylibrary and mylibrary2.
mylibrary does roughly this:

env.__gc = module_cleanup -- cleanup function
setmetatable(sentinel, env)
env.__module_sentinel_ud = sentinel

mylibrary2 does this:
env.__gc = module_cleanup -- cleanup function


With a test script that just does:
require "mylibrary"
require "mylibrary2"

I get the crash.

This is the stack trace:
WARNING: Frame IP not in any known module. Following frames may be wrong.
0x22105e
Lua5_1!luaD_precall+0x17d
Lua5_1!luaD_call+0x40
Lua5_1!GCTM+0xae
Lua5_1!luaC_callGCTM+0x14
Lua5_1!callallgcTM+0x9
Lua5_1!luaD_rawrunprotected+0x38
Lua5_1!lua_close+0x48
Lua5_1_standalone+0x105d
kernel32!BaseThreadInitThunk+0xe
ntdll32!__RtlUserThreadStart+0x70
ntdll32!_RtlUserThreadStart+0x1b


This is the output:
luaopen_mylibrary
luaopen_mylibrary2
DLL_PROCESS_DETACH (mylibrary2)

and the libraries were mapped in these addresses:
00030000 00035000   d:\trunk\bin\common\mylibrary.dll
00220000 00225000   d:\trunk\bin\common\mylibrary2.dll

So, mylibrary2 unloads first. Then when the sentinel of mylibrary is collected, attempts to call its __gc method but ends up calling the one at mylibrary2.

I hope I'm making sense now :)

Regards,
Ignacio Burgueño