lua string.gmatch can become stuck
tracked
TrishAce Resident
String.gmatch can become stuck in use after an error.
Take this example debug script:
local it = string.gmatch("hello world", "(%a)%2")
local ok1, err1 = pcall(it)
print("call 1:", ok1, err1)
local ok2, err2 = pcall(it)
print("call 2:", ok2, err2)
It outputs:
call 1: false invalid capture index %2
call 2: false gmatch iterator is already in use
While I would expect:
call 1: false invalid capture index %2
call 2: false invalid capture index %2
Log In
Tapple Gao
this is different than upstream luau:
$ slua string.gmatch.error.luau
call 1: false invalid capture index %2
call 2: false gmatch iterator is already in use
$ luau string.gmatch.error.luau
call 1: false invalid capture index %2
call 2: false invalid capture index %2
SuzannaLinn Resident
Tapple Gao
It's in the SLua modifications to get yieldability
M
Mercury Linden
updated the status to
tracked
SuzannaLinn Resident
It looks like it's happening this:
- When gmatch()'s iterator runs, it stores away some info and sets it to nil, to avoid it being called again from inside the iterator: https://github.com/secondlife/slua/blob/4116d7f6a38338cef7bbf6ab061c913682d432fd/VM/src/lyieldstrlib.cpp#L1162-L1169
- This info is restored before the iterator ends: https://github.com/secondlife/slua/blob/4116d7f6a38338cef7bbf6ab061c913682d432fd/VM/src/lyieldstrlib.cpp#L1210-L1215
- If there is an error during the processing the info is never restored, leaving it locked as "already in use".