Должно быть где-то тут ))
https://www.lua.org/source/5.1/lcode.c.html

Да нужно только найти место аллокации объекта, чтобы понять, как он связывается со стейтом

Я дурак и смотрел в основном код стандартных библиотек, то есть "что дёргаем", а не "как именно дёргаем".

Так, начало положено

Я пошёл от C-API

Далее, далее, далее

А вот и создание нового потока

Судя по всему, global_State у них у всех общий.

Вся аллокация и сборка мусора подвязаны на некий global_State, который и является экземпляром VM. Он не доступен пользовательскому коду, но создаётся в момент lua_open, который возвращает указатель на «главную корутину». Соответсвенно, каждая корутина обладает ссылкой на экземпляр VM, но с точки зрения GC это не очень важно, потому что «на самом деле» владеет управляемой памятью именно global_State. Впрочем, все lua_State используются сборщиком мусора для принятия решения о достижимости объекта.

В таком дизайне нет, никакого висячего указателя не будет, пока GC может хоть как-то (через стеки корутин, через глобальную таблицу) достучаться до объекта.

Отлично. Частично прояснилось, спасибо. Примерно к такому же выводу я пришёл в своих 3-4 последних сообщениях, где-таки добрался до global_State.
Значит проблема или в моём коде, или в коде библиотечной абстракции.

Но к каждой переменной всё равно привязан какой-то стейт, через который она обращается к глобальному стейту. Может ли протухнуть этот стейт?

Есть у нас глобальный стейт L, переменная a, созданная в корутине. a->L = L1 - дочерний стейт. G(a->L) == G(L).
Допустим, мы копируем эту переменную в глобальный скоуп, в котором всё имеет L, но пришла переменная с L1, который может помереть в любой момент.

Типа всё что в корутинах отправляется в глобал-стейт, по хорошему.

Отправляется кем? Виртуальной машиной или разработчиком, который использует C-api?

С точки зрения Lua VM никаких переменных нет, слоты на стеке. То есть утверждение не очень корректно. Это GC в VM ползает по стекам и решает, что протухло.

Что может пойти не так? Например, у вас есть userdata, которая не заанкорена нигде в Lua-коде (и в registry ее нет). Вот тогда она будет сколлекчена и попытка обращения будет неудачна. Потому что за память userdata отвевает Lua VM, а за начинку – хост.

Не, юзердаты никакой нет. Есть
sol::table table; в C++ (обёртка над табличкой), есть
sol::table get_table() { return table; }, которая даёт ссылку в луа, где ей пользуются из корутин примерно так:
get_table()[1] = "asd"
Помимо этого есть ещё и void set_table(sol::table t) { table = t; }, который так же могут вызвать из луа как set_table({})

При unrefе этой самой table (когда все корутины точно мертвы, но возможно не собраны сборщиком) крашится внутри lua_rawgeti, так как index2addr возвращает NULL

Луа 5.3, если что

Можно предположить, что код на плюсах был написан так, что был возможен следующий сценарий: 1) запомнили поинтер на таблицу 2) GC почистил таблицу внутри VM 3) в глобальную таблицу был помещён поинтер на очищенную таблицу