Судя по исходникам, он сравнивает некую последнюю глобальную версию с той, которая записана в этом инстансе ресивера

Ладно, попробую с вотчем

Я его раньше избегал, он странный какой-то. Может зря

есть энум, у которого есть ~190 вариантов. значения энума - структуры, часть из которых довольно развесисты, а часть - энумы, тоже со структурами в качестве значений. летает этот 190-уровневый энум через tokio::sync::mpsc.
в какой-то момент начинаю получать stack overflow (достаточно быстро, где-то на пятидесятом сообщении или даже раньше).
судя по стеку, валится именно отправка в канал.
есть ли какие-то умозрительные ограничения на размер структур\энумов? кажется, что не должно быть, но других причин sigsegv я пока найти не могу...

Ну в бокс их запихать. Стек - он как бы не резиновый. Точнее куча более резиновая чем стек

Число вариантов в енуме может коррелировать с размером дискриминанта только

Размер самого большого варианта будет размером енума

спасибо, попробую

какого дискриминанта?

В фарше вот например не так

а, я понял

В фарше число вариантов коррелирует с размером адт

ну да, clippy у меня ругается на то, что пара структур в этом энуме сильно больше остальных...

К тому же при отправке в очередь мпсц они накапливаются в этой очереди а не на стеке

Я бы посоветовал отловить сегфолт отладчиком , либо установить альтернативный стек для сигналов через sigaltstack

Чтобы узнать дело ли в оверфлоу

отловил уже, потому и говорю, что падает при отправке в mpsc. могу скинуть стектрейс.

Так вы же можете конкретную инструкцию увидеть

помогло, ещё раз спасибо.
но, тем не менее, странно. и правда, кажется, что не на стеке ж должен жить товарищ...

В Линуксе для этого даже отладчик не нужен