autodump hotkeys can run without acquiring a coresuspender under some conditions

[ab9rf]

Hitting Alt-K while a designation is being selected and while a DFHack overlay window is open but not selected (e.g. gui/reveal) will cause an assertion failure in dfhack_lua_viewscreen::getSelected for attempting to acquire the shared Lua state without holding the core suspender.

Replication process: Open gui/reveal. Click outside the window to make it nonactive; do not close it. Press x to begin a "remove designation" operation. Click somewhere to start designating a rectangle to remove designations. Hit Ctrl-K to trigger the hotkey for autodump-destroy-item. A production instance will hang (presumably due to deadlock); a developer build will assertion-fail on the assertion in DFHack::Core::getInstance().getLuaState() that requires isSuspended() to be true.

See Discord for more context.

[ab9rf]

additional information: the hotkey is being run on the render thread, which is ... not supposed to happen. it's not safe to access DF structures, or attempt to run DFHack Lua, from the render thread, because the simulation thread can be running concurrently

[SilasD]

Possibly related to DFHack/scripts#1595 , which I diagnosed as a rendering race condition, although sizzlins disagreed.

Edit: I saw that issue under DF 53.12.

[ab9rf]

I just tested, and this bug exists in DF 53.14 + DFHack 53.14-r2 and also in DF 50.14 + DFHack 50.14-r1.1. It's an old bug, and furthermore it likely wasn't caused by my changes in #5159, because 50.14-r1.1 predates #5159.

[ab9rf]

more additional information: the issue arises because the hotkey manager attempts to validate whether a hotkey is valid on the current screen before it mailboxes the hotkey for execution, but this test requires running Lua code if any current screen is a dfhack_lua_viewscreen as the virtual method called on a dfhack_lua_viewscreen is Lua code and thus requires a Lua state

one possible mitigation is to have Plugin::can_invoke_hotkey return false if top is a dfhack_lua_viewscreen in order to prevent accessing the Lua methods of a dfhack_lua_viewscreen from can_invoke_hotkey, which will always be called from DF's main (render) thread. another possible mitigation is to have the methods in dfhack_lua_viewscreen safety-check that they're in a safe context and soft-fail somehow if they aren't, but i don't like that very much

[ab9rf]

Possibly related to DFHack/scripts#1595 , which I diagnosed as a rendering race condition, although sizzlins disagreed.

Edit: I saw that issue under DF 53.12.

I am pretty confident this is not related.