2.1 crash using module with ffi
- From: William Adams <william_a_adams@xxxxxxx>
- To: "luajit@xxxxxxxxxxxxx" <luajit@xxxxxxxxxxxxx>
- Date: Wed, 22 Jan 2014 06:21:45 +0000
I get a crash trying to use a FFI function from a module.
Windows 8.1, 64-bit
LuaJIT 2.1, compiled as 32-bit
Unhandled exception at 0x75C11402 in tinn.exe: 0xC0000005: Access violation
executing location 0x75C11402.
Using the following:
-- routines.lua
local ffi = require("ffi")
local WTypes = require("WTypes")
ffi.cdef[[
BOOL
EnumProcesses (
DWORD * lpidProcess,
DWORD cb,
LPDWORD lpcbNeeded
);
]]
local Lib = ffi.load("psapi");
return {
EnumProcesses = Lib.EnumProcesses,
}
And then this:
-- testfile.lua
local routines = require("routines")
function processIds(self)
-- enumerate processes
print("processIds, 1.0")
local pProcessIds = ffi.new("DWORD[1024]");
local cb = ffi.sizeof(pProcessIds);
local pBytesReturned = ffi.new("DWORD[1]");
print("processIds, 2.0")
--local status = Lib.EnumProcesses(pProcessIds, cb, pBytesReturned);
local status = routines.EnumProcesses(pProcessIds, cb, pBytesReturned);
print("processIds, 3.0")
--print("processIds: ", status)
if status == 0 then
local err = errorhandling.GetLastError();
print("ERROR: ", err)
return false, err;
end
local cbNeeded = pBytesReturned[0];
local nEntries = cbNeeded / ffi.sizeof("DWORD");
print("Needed: ", cbNeeded, nEntries)
local idx = -1;
local function closure()
idx = idx + 1;
if idx >= nEntries then
return nil;
end
return pProcessIds[idx];
end
return closure;
end
I can get a crash. There's a lot of other stuff in between, but the essentials
seem to be this.
1) If I include the contents of routines.lua directly into the test program, I
won't get a crash
2) If I simply access the function in the library diretly (also from the test
file) I won't get a crash
3) If I have things setup as they are, I WILL get a crash. (access violation).
there are coroutines and loops involved, and without all that, the crash
doesn't seem to occur. So, I'm not sure if something else puts the runtime in
a funky state and this is just a symptom.
This is new to 2.1. With 2.0.2 I didn't get this behavior.
I know that accessing library functions directly from the ffi.load() thing is
much more efficient, but circumstances are such that I need an intervening
table.
I don't know if the inclusion through an external modules makes the difference
or not.
I literally have thousands of other calls that don't exhibit this behavior. It
might be that the address where this function is loaded in memory has some
affect on the outcome. Maybe I'm just getting lucky in most other cases.
I also noticed the same behavior when trying to access the latest Kinect
library. One function works, but the rest end up with a crash.
Anyone else see something like this?
-- William
===============================
- Shaping clay is easier than digging it out of the ground.
Other related posts:
