Very special Windows problem with AddVectoredExceptionHandler and LuaJIT
Posted: Sat Sep 09, 2017 7:44 am
Hi 
, I hope I won't waste anyone's time and sorry for not uploading a project. The problem is this:
I use Love 10.2 64-Bit to load a Windows Dll and call it via the way that LuaJIT has invented, declaring and directly calling a _cdecl function. It usually works, and what also works is code in the Dll that calls more Windows API functions. And with mingw-w64 even that thing that I'm posting, AddVectoredExceptionHandler, will work like a charm. I can use it together with addr2line to get the line number of a C code that creates an access violation.
But one thing doesn't work. I want to call AddVectoredExceptionHandler the same way but compiling the Dll with Visual C++ 2013 instead of mingw-w64. At first everything is fine, it all returns and subsequent lua-print()s will output text into the console. Then, about 200ms later, LuaJIT crashes with this line "PANIC: unprotected error in call to Lua API (13)" or this line "PANIC: unprotected error in call to Lua API (6)".
Actually that C-crash-handling was something that I really wanted to do, and I want to use Visual Studio because of some other libs and keeping it all simple. Now it seems I'll need to compile and debug something in LuaJIT that even doesn't crash immediately. Afaik the LuaJIT error could mean something like out of memory.
Anyone has an idea? And why does it work with mingw-w64? Will AddVectoredExceptionHandler add any recursion or eat up memory?
Thanks for any help, including general advice.
Kind regards
The C code backend.c for backend.dll
The Lua code
, I hope I won't waste anyone's time and sorry for not uploading a project. The problem is this:I use Love 10.2 64-Bit to load a Windows Dll and call it via the way that LuaJIT has invented, declaring and directly calling a _cdecl function. It usually works, and what also works is code in the Dll that calls more Windows API functions. And with mingw-w64 even that thing that I'm posting, AddVectoredExceptionHandler, will work like a charm. I can use it together with addr2line to get the line number of a C code that creates an access violation.
But one thing doesn't work. I want to call AddVectoredExceptionHandler the same way but compiling the Dll with Visual C++ 2013 instead of mingw-w64. At first everything is fine, it all returns and subsequent lua-print()s will output text into the console. Then, about 200ms later, LuaJIT crashes with this line "PANIC: unprotected error in call to Lua API (13)" or this line "PANIC: unprotected error in call to Lua API (6)".
Actually that C-crash-handling was something that I really wanted to do, and I want to use Visual Studio because of some other libs and keeping it all simple. Now it seems I'll need to compile and debug something in LuaJIT that even doesn't crash immediately. Afaik the LuaJIT error could mean something like out of memory.
Anyone has an idea? And why does it work with mingw-w64? Will AddVectoredExceptionHandler add any recursion or eat up memory?
Thanks for any help, including general advice.
Kind regards
The C code backend.c for backend.dll
Code: Select all
static LONG WINAPI
crashhandler(EXCEPTION_POINTERS* ExceptionInfo)
{
////////////// UPDATE: don't test it like this: return EXCEPTION_CONTINUE_EXECUTION;
// it will break any existing handling by continuing after the causal code
// UPDATE: this is roughly how one should ignore LuaJIT's custom exception codes
switch(ExceptionInfo->ExceptionRecord->ExceptionCode)
{
// exceptions documented by Microsoft
case EXCEPTION_ACCESS_VIOLATION: // set some text
break;
// etc
// exceptions NOT documented by Microsoft
default: return EXCEPTION_CONTINUE_SEARCH;
}
// print some debug info
// just testing, don't do anything for now
}
__declspec(dllexport) void installcrashhandler()
{
AddVectoredExceptionHandler(TRUE, crashhandler);
}
Code: Select all
local ffi = require("ffi")
ffi.cdef[[
void installcrashhandler();
]]
backend = ffi.load("backend")
-- directly in love.load() or on a mousepress
backend.installcrashhandler()
And that I added an exception handler and expected it to not being called because this was the case with mingw.