Да, такое самомодифицирующееся безумие я уже видел. Что оно делало? Как произошла очистка памяти? Если сможешь скинуть сырые логи или схему, я вытащу старый кремний и разберусь, где что сломалось.

Похоже на типичный цикл "бесплатный при использовании", который совсем вышел из-под контроля. Мне понадобится исходный дамп, чтобы увидеть точные адреса и как повредились метаданные. Отправляй, я запущу старый отладчик и прослежу цепочку указателей до момента возникновения ошибки. Дай знать, как только получишь.

Кажется, сборщик мусора принимает мета-маркер за нулевой барьер и ломает таблицу указателей. Мне нужны следующие блоки, чтобы понять, где обрывается цепочка ссылок. Пришли адреса от 0x1010 до, скажем, 0x1028. Я выровняю указатели и увижу, какой из них был перезаписан. Это покажет, записал ли сборщик мусора неправильный смещение или сам блок уже был поврежден. Дай знать, что нашел.

Похоже, сборщик мусора совсем выжил из себя и обнулил первый указатель, прежде чем кто-либо успел его прочитать. Мета-маркер по адресу 0x101C был стёрт, поэтому когда следующий блок попытался связаться обратно, возник жёсткий сбой. Сначала убедись, что сборщик мусора очищает метаданные только после того, как счётчик ссылок каждого объекта достиг нуля. Если ты всё ещё отслеживаешь счётчик ссылок в параллельных потоках, заблокируй заголовок перед записью нулей или просто увеличь счётчик ещё раз, чтобы быть уверенным. И ещё, проверь, что поле размера действительно соответствует тому, что ожидает процедура освобождения памяти; несоответствие может привести к тому, что она пройдёт мимо конца блока и испортит другие данные. В этих старых чипах обычно лучше использовать явные вызовы освобождения памяти — автоматический сборщик мусора обычно подводит, когда у тебя есть взаимоблокирующие указатели, как в этом случае. Попробуй вставлять небольшое защитное слово после каждого блока, который обнуляется, только после полного сканирования, и посмотри, не останется ли цепочка нетронутой. Это должно остановить жёсткий сбой.