-
Notifications
You must be signed in to change notification settings - Fork 40
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
DMD GC causing segfault #9
Comments
I haven't been able to reproduce this bug. Starting from the bottom of the provided snippet, could you try removing one line at a time until the bug goes away? I think that would help pinpointing where the erronous LuaObject is created. |
I have the same issue. I'm on 64-bit Ubuntu and I had to change a few "int"s to "long"s to get it to compile. All that is necessary to cause the segfault is to create a LuaState. Here's my backtrace with some more symbols: #0 0x000000000040877c in lua_rawgeti (L=0x6bbaa0, idx=-10000, n=0) at lapi.c:573 As you can see, it happens when destructing LuaReference. Here is the offending code in lapi.c:
Here are the values of the vars: It seems a bit odd to me... not sure why it's crashing. |
A little more investigation reveals that setobj2s is a macro. Here it is again, expanded:
576 is the offending line. If you take a look at my previous post, you'll see L->top is 0x0, so o1 is a null pointer that is being accessed. |
I believe I've found the problem. When the LuaState object is GC'd, lua_close() is called in the destructor and then afterwards the LuaReference destructor is called, which calls luaL_unref() with a now invalid lua_state. I'm not sure what the best way to go about fixing it is, so I'll leave that to you :-). |
Sorry for replying late, I'm aware of the problem (also mentioned in other issues like "Calling a delegate containing a LuaFunction throws an exception"), and I decided long ago to refactor the LuaObject and LuaState objects into structs (which also makes use of LuaObject a bit more performant), but I've never gotten around to doing it. There is a temporary solution which can help in some applications, but the problem and solution should really be mentioned in the docs (since I'm so slow in fixing it):
(Requires that you import the C API) The workaround has some side effects. The LuaD panic handler throwing an exception is not installed by default. See the source code of the two constructors for LuaState on how to solve this. |
No problem. Your workaround still doesn't work because of _G and _R created in the LuaState ctor. If I manually delete these in the LuaState dtor, it fixes the crash, though. I guess _G and _R are the objects that we're getting destructed after the lua_state was closed. I'm not sure if this fixes the underlying problem (I would guess not), as I'm not that familiar with Lua, or D for that matter, but at least for me, it seems to stop the crashing. |
Right, nice find! Indeed, I don't think it really fixes the underlying problem. The delete operator itself is deprecated, and it still leaves the problem of other LuaObject references hanging around after the LuaState is gone. |
Confirmed on a 64-bit platform, also confirmed the workaround in issue #11 (adding that you need to import luad.c.all in order to make luaL_newstate() work, of course). |
LuaObject hierarchy are now structs, this bug should be fixed |
Code here http://paste.pocoo.org/show/270340/
Back trace here http://paste.pocoo.org/show/270342/
The text was updated successfully, but these errors were encountered: