вообще не факт. Может у тебя деструктор дважды вызывается где-то. Если в этом где-то был вектор, ты ловишь такую чепуху. Если там trivial структура, то ты просто не замечаешь разницы в наблюдаемом поведении. Но ошибка-то есть в обоих случаях

а ежели "и так работает" значит и в отладке помощь не нужна, да? )

При добавлении любого std::string в структуру оно начинает сбоить

+

Короче дебаггером работать надо

Я и работаю вижловским

Можешь попробовать скомпилить под линух и пройтись ubsan

я могу посоветовать только перечитать мои советы выше

Это просто у тебя проявляется проблема или нет, это не значит, что ты её исправил.
Очевидно, что все зависит от размера объекта

кстати надо будет потом почистить этот тредик

он не понимает, что едет по памяти, а ты советуешь пойти на другую ось с другими правилами :) ну так себе помощь

Почему?

+

ну вообще, судя по асм-коду,
std::vector<shader::VarToReg>::~vector вызывается на this+0x40
а
std::vector<unsigned int>::~vector на this+0x60

проверь, что offsetof(TranslationState, var_to_regs) - это 0x40

потому что чат всё-таки не про помощь в отладке кода по стектрейсу

Так оно и есть

у меня тоже такая проблема. Часто пытаюсь искать ошибку слишком локально

например лезу в корки хотя причина assert'а в логах есть )

это значит, что компилятор где-то по смещению 0x60 увидел std::vector<unsigned int>
возможны такие варианты:
1. он был там раньше и остался где-то в артефактах сборки
2. где-то нарушен ODR и есть структура с тем же именем
3. это баг компилятора
4. ???

предлагаю для начала целиком пересобрать проект, а потом в отладчике посмотреть получившийся лэйаут TranslationState

ещё можно понатыкать отладочных принтов с доступом к разным полям, чтобы понять, какие у них смещения (+ sizeof)

я бы поставил на исключение в деструкторе