Very special Windows problem with AddVectoredExceptionHandler and LuaJIT

[markus]

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

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);
}

The Lua code

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()

[raidho36]

Could be a quirk or a bug in MSVC. Maybe it's a LuaJIT bug. No software is perfect.

Also you're continuing execution past the point where any reliability is even implied, so you shouldn't expect it to work at all.

The crash message itself indicates that there's an invalid Lua API command somewhere (such as using nil where it's not allowed) that's executed without a protected call wrapper. If I had to guess, it's simply because Lua state gets corrupted - nearly entire Lua realm is wrapped in xpcall, so no error should escape it, not after the framework began initalizing and not before xpcall crash handler is envoked. You also get a nondescript number error code instead of error message, that's a hint that something goes wrong internally, too.

[markus]

Thanks a lot! I have changed it to CONTINUE_SEARCH and now noticed that the handler is being called, uh. It seems that LuaJIT throws its very own 0xe24c4a02 exception, google tells me a lot about that number and LuaJIT.

This will at some day work, thanks again.

[raidho36]

The number is a memory address, you'll never get any useful info out of that. You can try dereferencing it though.

[markus]

The crash message itself indicates that there's an invalid Lua API command somewhere (such as using nil where it's not allowed) that's executed without a protected call wrapper. If I had to guess, it's simply because Lua state gets corrupted - nearly entire Lua realm is wrapped in xpcall, so no error should escape it, not after the framework began initalizing and not before xpcall crash handler is envoked. You also get a nondescript number error code instead of error message, that's a hint that something goes wrong internally, too.

Yes, the number isn't telling anything anymore. Continuing execution instead of printf was bad testing. And that I added an exception handler and expected it to not being called because this was the case with mingw.

It's now not as obscure as before.

The number is a memory address, you'll never get any useful info out of that. You can try dereferencing it though.

The (13) and (6) or the exception? The 0xE24C4A02 comes from ExceptionInfo->ExceptionRecord->ExceptionCode and seems to be some magic number from LuaJIT, when I google it.

[markus]

Seems when I just ignore the undocumented exception codes like 0xE24C4A02 and by returning CONTINUE_SEARCH let LuaJIT handle it, then I'm fine. I think it works! Again.. tnx.

https://www.freelists.org/post/luajit/F ... n-luajit,1