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

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

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

Looks like the collector went berserk and zeroed the first pointer before anyone had a chance to read it. The meta marker at 0x101C was wiped out, so when the next block tried to link back you got a hard fault. First check that the GC only clears metadata after every reference counter has hit zero. If you’re still tracking use‑count in parallel threads, lock the header before writing the zeroes or bump the counter once more just to be safe. Also make sure the size field really matches what the free routine expects; a mismatch can cause it to walk past the end of the block and clobber other data. In these old chips you usually prefer explicit deallocation calls—auto‑GC tends to bite when you have interlocked pointers like this. Try inserting a small guard word after each block that gets zeroed only after a full scan, and see if the chain stays intact. That should stop the hard fault.