debug.getinfo does not guard against '>' as the first character in
what/options. This can result in lua_getinfo expecting a function on the
top of the stack but db_getinfo not pushing it, when a call stack index
is supplied instead of a function.
When a different thread is inspected, this can result in stack top being
reduced by one every time debug.getinfo is called.
After reducing stack top of a different thread, calling debug.getinfo
with a function object instead of a call stack index can result in the
function object being written somewhere in the middle of the stack of
the other thread as can be seen in the following test.
local c = coroutine.create(function(changed)
coroutine.yield() -- Here debug.getinfo will write the print
function into 'changed'.
local value = "Random"
debug.getinfo(c, 1, ">") -- This should 'error bad argument #3 to
'getinfo' (invalid option)' as debug.getinfo(c, 1, "X") does.
assert(debug.getinfo(c, 1, ">f").func == value) -- Reading the local
variable 'changed' from the coroutine.
debug.getinfo(c, print, "")
local _, val = coroutine.resume(c)
-- assert(val == value, "Value changed") -- This should be true,
assert(val == print) -- but this is
I am aware that using the debug library wrong can cause unexpected
behaviours, but debug.getinfo already errors when an unexpected option
is supplied, therefore '>' shouldn't be allowed too.
> debug.getinfo does not guard against '>' as the first character in
> what/options. This can result in lua_getinfo expecting a function on the
> top of the stack but db_getinfo not pushing it, when a call stack index is
> supplied instead of a function.
(I'am afraid we've not answered this yet.) You are right; thanks for the