Re: [BUG?] Segmentation fault in lua_error() - easily reproducible
- From: "Sergei Zhirikov" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "sfzhi@xxxxxxxxx" for DMARC)
- To: "luajit@xxxxxxxxxxxxx" <luajit@xxxxxxxxxxxxx>
- Date: Sat, 13 Dec 2014 09:50:21 +0000 (UTC)
See below.
________________________________
From: "imzyxwvu@xxxxxxxxx" <imzyxwvu@xxxxxxxxx>
To: "luajit@xxxxxxxxxxxxx" <luajit@xxxxxxxxxxxxx>
Sent: Saturday, December 13, 2014 5:50 AM
Subject: Re: [BUG?] Segmentation fault in lua_error() - easily reproducible
>lua_State created with luaL_newstate isn't a thread.
Yes, it is very much a thread. It is even called so in the Lua reference manual.
> If you want to create a thread lua_State, use lua_newthread.
Yes, you can do that - I have mentioned it - but that will not change anything
- just try it.
> And lua_loadstring pushes a function instead of a thread.
What do you man by "instead"? Yes, it pushes a function and that is all it
needs to do.
> It should be called with lua_call or lua_pcall but not lua_resume.
What makes you think so? This is just the traditional way, but not the only
valid one.
> It should have throw an error of the wrong type and lead to a Lua panic there.
Again: no, it shouldn't and it doesn't. There is no wrong type anywhere.
Anyway, I don't want to keep arguing about the irrelevant things. The
segmentation fault is what this is about. And it occurs regradless of whether
you use lua_newthread() or not. So please, let's drop that part of the
discussion. If you insist, I can post another example that uses
lua_newthread(), which will differ by one line, but again: that will not change
anything.
在 2014年12月13日，7:58，"Sergei Zhirikov" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted
sender "sfzhi@xxxxxxxxx" for DMARC) 写道：
No offense, but I've got an impression that you didn't quite understand the
code. Where did you see a stack index of 0? There is no stack index explicitly
specified anywhere at all. The code, doesn't just create a function, it *does*
run it - that's what the call to lua_resume() is for. And it does resume a
coroutine, which, like any coroutine, consists of a lua_State and a function
that runs in it. The best proof of that is that it actually runs and the call
to coroutine.yield() does *not* throw an error. But that is all beside the
point. The point is that calling lua_error() in a lua_State that is suspended
causes a segmentation fault. The whole thing about loading the function that
calls yield() is only to bring the lua_State to the suspended state - nothing
more. If you don't feel comfortable calling the main Lua thread a coroutine,
you can call lua_newthread() to create a new one and then resume it - that
won't change the ultimate result: you will get a segfault.
>
>________________________________
> From: Alex <initrd.gz@xxxxxxxxx>
>To: luajit@xxxxxxxxxxxxx
>Sent: Friday, December 12, 2014 9:55 PM
>Subject: Re: [BUG?] Segmentation fault in lua_error() - easily reproducible
>
>Actually, there's a lot errors in the code as well. 0 is never a valid stack
>index, yet you use it as one in lua_resume. Additionally, calling
>coroutine.yield() when not inside of a coroutine will throw an error.
>
>
>On Fri, Dec 12, 2014 at 3:52 PM, Alex <initrd.gz@xxxxxxxxx> wrote:
>> luaL_loadstring(lua, "coroutine.yield()");
>>
>>
>>This just loads the string and creates a function from the contents; it
>>doesn't run it. You then try to resume the resulting function, which isn't a
>>coroutine.
>>
>>
>>On Fri, Dec 12, 2014 at 3:44 PM, Sergei Zhirikov
>><dmarc-noreply@xxxxxxxxxxxxx> wrote:
>>Hi,
>>>
>>>I've encountered this case of a consistent segmentation fault in LuaJIT
>>>(tested with 2.0.3 on x86 and x86_64).
>>>The following simple example allows to reproduce it:
>>>
>>>#include <lua.h>
>>>#include <lualib.h>
>>>#include <lauxlib.h>
>>>#include <stdio.h>
>>>
>>>int main()
>>>{
>>> lua_State *lua = luaL_newstate();
>>> luaL_openlibs(lua);
>>> luaL_loadstring(lua, "coroutine.yield()");
>>> int res = lua_resume(lua, 0);
>>> printf("res=%d, top=%d\n", res, lua_gettop(lua));
>>> lua_pushliteral(lua, "test");
>>> lua_error(lua);
>>> return 0;
>>>}
>>>
>>>This code is supposed to panic, but it results in a segmentation fault
>>>inside lua_error() instead. Admittedly, this not a very common usage
>>>pattern, but calling lua_error() on a suspended Lua thread can be useful
>>>sometimes. Also, the "classic" Lua implementation doesn't have a problem
>>>with this usage.
>>>
>>>I'm wondering, can this be fixed with a simple patch?
>>>
>>>Thanks & regards,
>>>
>>>Sergei.
Other related posts:
