Custom blocks in lambdas execute with the thread that defined the lambda

[the-can-of-soup]

This is a cross-post of a Discord bug reports post with the same name. See that post for downloads of files that could not be uploaded here.

Found this while trying to debug Inconsistent string builder error when defining a lambda in different places.

Summary

Whenever a custom block is executed from within a lambda, its thread variable is set to the thread that defined the lambda; not the one executing it.

Effect

This is a somewhat serious issue because it enables the usage of dead and orphaned threads as if they were the current thread, and can cause a ton of issues related to per-thread data storage, including I believe the help post I linked.

I believe the reason the issue I discussed in the help post happened is because the YASE string builder set the context data on thread, but the append [STRING] to builder block checks for it on util.thread (it is not compiled), and I believe the latter properly retrieves the executing thread rather than the defining one. This causes a mismatch and leads to the append [STRING] to builder block thinking it is not in a string builder due to lack of context data on the executing thread. Conversely, it leads to a buildup of the context stack on the defining thread, which could potentially cause a memory leak if the lambda is called repeatedly.

Example

Update: I have confirmed that util.thread in non-compiled blocks is indeed the executing thread, so this issue only applies to thread in compiled blocks (notice the mismatch in the final two logs).

Workaround