Треснутый кирпич

Вечер добрый.

Если вы знаете, что такое константая ссылка, рекомендую вам пропустить этот абзац. Сегодня решал рутинную, но достаточно сложную задачу: многопоточность, COM/.NET, web-сервисы... Часа за четыре изваял скелет и за пару отладочных запусков освоил тестовые данные. Подключил графический интерфейс, перевел обработку в рабочий поток, стал кормить реальными данным — затык, код аварийно завершается в чистом поле при работе с менеджером памяти. Бинарным поиском, с тихими матами и пинанием стола, в расстроенных чувствах два часа ушли на поиск источника ошибки. И что вы думаете? Ладно бы это был свой родной код (себя по лбу треснул, отметил галочкой прецедент в мозге и гуляй), а тут — бац! — ошибка в библиотеке внутреннего пользования, оказавшейся в списке подозреваемых последней. Причем, классом-виновником пользуются полдюжины продуктов каждый день. Для сравнения, это тоже самое, что построить дом и на следующее утро на развалинах найти пару треснувших кирпичей в основании. Одним словом, подстава.

Если вы не знаете, что такое константая ссылка, рекомендую вам пропустить этот абзац. На удивление, врагом народа оказался класс, отвечающий за хранение и разбор поставочных версии бинарных файлов. Я получал этот объект от клиента по константой ссылке и не мог запросить неконстантый геттер, поэтому, решив играть честно, сделал локальную копию, у которой уже спрашивал интересующие меня данные. Как потом оказалось, этот класс использовал ручное распределение памяти (new/delete[]) и не имел копирующего конструктора или оператора присваивания. Естественно, все указатели убивались дважды. Спустя неопределенное число операций, система шла бананами. :S

Пропустите этот абзац! Весь смех в том, что сбоящий код очень старый, он "ждал" меня тринадцать лет! Уууу, где тут у вас машина времени?