Re: [LuaJIT] JIT'd Code Causing Segfaults on Linux x86?

[Alex <initrd.gz@...>]

The FFI headers I'm using were parsed from GLEW on my Windows x64, which is probably why they are there. I'll try re-processing the headers tomorrow in Linux and see if it clears up.

Also, GLEW uses #define macros to redirect most (but not all) OpenGL functions to its own. Since FFI currently doesn't support #defines, I had to implement a workaround, which is basically going through the GLEW header, parsing the OpenGL function and its redirection, then creating a giant Lua table with the GL functions as keys and the redirection as values, then redirecting the calls as such:

gllib = setmetatable({}, {__index=function(self,k) return lookup[k] and glew[lookup[k]] or gl[k]})

I'm not quite sure how else to redirect them short of using the GLEW internal functions everywhere. Unless... Maybe I can add lines such as this to the FFI header?

void (*glDoSomething)(int a) = &__glewDoSomething;

I'll have to test that and see. Thanks for all the help!

On Wed, May 2, 2012 at 2:15 PM, Mike Pall <mikelu-1205@mike.de> wrote:

Alex wrote:
> I've ran it again and uploaded the results to the same URLs. Looks like the
> backtrace is pointing to 0xb74a8877 (line 1413 of the jdump).

Umm, what's your declaration for glTexCoord2fv()? Because it looks
like you used __stdcall, but the actual function is a plain
__cdecl (or behaves as such). This causes the C stack to get
misaligned in the JIT-compiled code on x86 and bad things happen.

Could it be that you used __stdcall declarations for Linux, too?
That's certainly wrong, as these are only used under Windows.

BTW: You can just leave __stdcall out and it'll be auto-detected
by the LuaJIT FFI on Windows.

[__stdcall is a legal calling convention on all x86 platforms, but
rarely used outside of Windows. The declaration is ignored on x64,
so you got away with it there.]

BTW: Whatever you're doing to resolve GL function calls is rather
inefficient. That's the stuff around lujgl.lua:39.

--Mike