

<HTML><BODY><div>Hi team, </div><div> </div><div>QA LGTM</div><div> </div><div> </div><div data-signature-widget="container"><div data-signature-widget="content"><div>--<br>Vitaliia Ioffe</div></div></div><div> </div><div> </div><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;">Четверг, 19 августа 2021, 10:42 +03:00 от Kirill Yukhin via Tarantool-patches <tarantool-patches@dev.tarantool.org>:<br> <div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_16293589770976284916_BODY">Hello,<br><br>On 16 авг 13:19, Sergey Kaplun wrote:<div class="mail-quote-collapse">> This change is a kind of revertion of commits<br>> ed412cd9f55fe87fd32a69c86e1732690fc5c1b0 ('Update cur_L on exceptional<br>> path') and 97699d9ee2467389b6aea21a098e38aff3469b5f ('Fix cur_L tracking<br>> on exceptional path').<br>><br>> When an error is thrown on the coroutine that is not the one being<br>> currently executed, `cur_L` is not set up. Hence, when the running trace<br>> exits at assertion guard right after the error is caught, Lua state is<br>> restored from the incorrect `cur_L`. As a result the resulting stack is<br>> inconsistent and the crash occurs.<br>><br>> Aforementioned patches fix the behaviour only for x86/x64<br>> architectures. This patch updates the `cur_L` within `lj_err_throw()` to<br>> the given lua_State, where the error is raised, since this is the only<br>> coroutine that can proceed later. Also, it removes unnecessary<br>> restorations of `cur_L` at C and FF exception handlers in the VM.<br>><br>> Nevertheless, throwing an error at non-currently executed coroutine is a<br>> violation of Lua/C API. So, in the nearest possible future this patch<br>> should be replaced within the corresponding assert.<br>><br>> Resolves tarantool/tarantool#6189<br>> Relates to tarantool/tarantool#6323<br>> Follows up tarantool/tarantool#1516</div><br>LGTM.<br><br>--<br>Regards, Kirill Yukhin</div></div></div></div></blockquote><div> </div></BODY></HTML>