Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segmentation fault when assigning a Lua callback to a C struct #25

Closed
niess opened this issue Dec 22, 2020 · 2 comments
Closed

Segmentation fault when assigning a Lua callback to a C struct #25

niess opened this issue Dec 22, 2020 · 2 comments

Comments

@niess
Copy link

niess commented Dec 22, 2020

Hello,

thank you for this great work :)

I am trying to adapt an existing LuaJIT+ffi project such that it could run with Lua as well using the cffi package. Doing so I am stuck with the following use case. When assigning a Lua callback to a C struct I get a segfault. Yet it works with LuaJIT. Below is a minimal example:

local ffi = jit and require('ffi') or require('cffi')

ffi.cdef([[
struct structure {
        void (*callback)(void);
};
]])

local structure = ffi.new('struct structure')
structure.callback = function () end

The last line gives a segfault on Debian using Lua 5.4+cffi. What could be the reason?

@q66 q66 closed this as completed in 51ccc2f Dec 22, 2020
@q66
Copy link
Owner

q66 commented Dec 22, 2020

okay, that's fixed now, but generally don't do this; you have no way to :free() the callback afterwards, so you leak resources, and with luajit it's especially bad considering the callback limits

you should always cast the lua function first, then save the result, pass it where you want it, and explicitly :free() the callback once you're done with it

@niess
Copy link
Author

niess commented Dec 23, 2020

Thanks!

I missed this point indeed. Usually my application uses only a few callbacks. Yet it could be problematic indeed. I will change this and make sure to :free().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants