Open John-Colvin opened 9 years ago
A cursory look at the backtrace seems to suggest that there's a GC-allocated array containing LuaObject
somewhere inside it (the other high level types are composed with LuaObject
). The array gets finalized after a GC-allocated (probably straight-up new
'd) LuaState
instance.
I've thought about this issue before but it wasn't critical until recently. Maybe a solution would be to change LuaObject
to use a custom reference counting mechanism that supports the necessary logic to ensure the underlying lua_State*
is only closed when both the LuaState
owner and all LuaObject
references are gone.
I assume a LuaObject is guaranteed to be associated with only one LuaState, yes?
Just off the top of my head: if LuaState can know about all its LuaObject's then it can scan through them all in its destructor and manually call their destructors where necessary (being careful not to use the GC inside a destructor that is itself called by the GC). It will be relatively slow, but it might not matter that much seeing as LuaState destruction should be pretty rare and outside any hot paths.
This may be the same issue, or it might not be.
But everything works for me except writing a D module for use in Lua. That segfaults. Tried it on two different machines both running arch linux 64 bit.
There's also another question about scope for building a related project to work with LuaJIT, which is used by Facebook's iTorch and can be used interactively from the Jupyter/ipython notebook. I am not sure, but it seems to me the sensible approach with LuaJit is to make use of it's FFi interface - you can just specify C headers as a string. It can deal with C structs and C 'arrays' natively and allows you to create metatables for C functions and data structures.
So starting from base zero, what I am inclined to do there is use Adam Ruppe's dtoh to generate the C headers. But one would still need to wrap D methods and arrays (turning a D array into a ptr/length pair and adding some sugar) on both the D and Lua side.
I guess you don't have time or interest to work on this together, but I thought I would mention my idea here out of courtesy. I may post something on the forum when time.
Laeeth.
But everything works for me except writing a D module for use in Lua. That segfaults. Tried it on two different machines both running arch linux 64 bit.
Assuming you are building a shared library; are you initializing the D runtime? A segfault report isn't very useful without at least a stack trace.
There's also another question about scope for building a related project to work with LuaJIT, which is used by Facebook's iTorch and can be used interactively from the Jupyter/ipython notebook. I am not sure, but it seems to me the sensible approach with LuaJit is to make use of it's FFi interface - you can just specify C headers as a string. It can deal with C structs and C 'arrays' natively and allows you to create metatables for C functions and data structures.
You can already use LuaJIT simply by linking with it. Completing the higher level interface built on the standard Lua C API is a priority over optimizing for LuaJIT's non-standard interfaces.
Apropos this issue, I have been working on a patch which turned out to be fairly involved but it shouldn't be a problem in theory. I just need to plow through various bugs.
Hi - yes I have tried initializing the D runtime, both via the Runtime.initialize and the C version. I'll try to get a stack trace for you in coming days. The FFI interface for LuaJit may be different from the main Lua interface, but it's hard to see what can be less standard about the interface itself. (One obviously needs to wrap it on the Lua side with C metatable entries, and maybe that's what you mean). I wasn't suggesting you do that, but I might find it necessary to do for my work, and just wanted to let you know in case it was helpful in some way. Will take some time before I can start on it though, and someone else might be helping me. So I am using iTorch which has LuaJit built in to torch. Do I need to change that build at all, or will it be enough just to change the compilation for LuaD to link with libluajit (or whatever its called) rather than liblua? Thanks. Laeeth. On Thu, 2015-09-17 at 13:40 -0700, JakobOvrum wrote:
But everything works for me except writing a D module for use in Lua. That segfaults. Tried it on two different machines both running arch linux 64 bit. Assuming you are building a shared library; are you initializing the D runtime? A segfault report isn't very useful without at least a stack trace. There's also another question about scope for building a related project to work with LuaJIT, which is used by Facebook's iTorch and can be used interactively from the Jupyter/ipython notebook. I am not sure, but it seems to me the sensible approach with LuaJit is to make use of it's FFi interface - you can just specify C headers as a string. It can deal with C structs and C 'arrays' natively and allows you to create metatables for C functions and data structures. You can already use LuaJIT simply by linking with it. Completing the higher level interface built on the standard Lua C API is a priority over optimizing for LuaJIT's non-standard interfaces. Apropos this issue, I have been working on a patch which turned out to be fairly involved but it shouldn't be a problem in theory. I just need to plow through various bugs. — Reply to this email directly or view it on GitHub.
So I am using iTorch which has LuaJit built in to torch. Do I need to change that build at all, or will it be enough just to change the compilation for LuaD to link with libluajit (or whatever its called) rather than liblua?
Yes, that will be enough. LuaJIT is designed to work as a drop-in replacement.
Note that the Lua version supported by LuaD is 5.1.x.
stack trace:
| | | |
| | _| |_
| |/ | '**/ | ' \
| | () | | | (| | | |
//|| _**|| |_|
JIT: ON SSE2 SSE3 SSE4.1 fold cse dce fwd dse narrow loop abc sink fuse th> require 'module'
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff747aac4 in pthread_mutex_lock () from /usr/lib/libpthread.so.0 (gdb) backtrace
From 2.067 onwards, structs on the GC heap (with exception of in AAs until 2.068.0) will have their destructors called before being freed/collected. I suspect that this change is the cause of these segfaults.
Here's a backtrace: