Рабочее :: Некрокод

Довелось мне тут заняться поиском причины segmentation fault в коде, написанном на Ada (для некоторых хихикающих в данный момент людей «ты же говорил в аде нет сегфолтов» — читаем дальше 🙂 )

Начнем, пожалуй, с того, что код был написан в 1986 году. Конечно, он изменялся и потом несколько раз, но так как он «Just works» — особо никто не вникал даже в то, как он работает ибо написан был сторонней компанией. Код этот — UNAS (не уверен, что проект еще жив). Проблема — при выходе из утилиты мониторинга эта самая утилита падает в coredump. Взял я в руки gdb, нашел строку, в которой идет обращение по неправильному адресу в строке 6843 (!) файла <что-то-там>-services.adb и, почуствовав неладное полез смотреть.

Судя по всему, код писали Сионисты — ибо адресная арифметика повсюду, вместо того, чтобы использовать ссылочные типы, которые в языке с 1983 года и вполне себе безопасны, они сгородили работу в классическом стиле (что-то вроде Address = Var’Address) и дальше пошли таскать этот адрес по всем потокам. Естественно в один прекрасный момент (а именно при закрытии сокетов) программа пытается читать из адреса, который был перед этим освобожден в другом потоке. И вот вместо более-менее легко отлавливаемоего Constraint_Error получаем всю прелесть целого дня бурной любви втроем (я, gdb и helgrind), чтобы отловить эту мерзость. К слову helgrind нашел больше 1000 возможных гонок (race conditions), что в общем-то неудивительно, ибо вместо встроенных в язык средств синхронизации повсюду используются самописные блокировки.

К чему это я? Мораль сей басни такова — учитесь пользоваться инструментами, с которыми работаете, будь то язык программирования, молоток или кухонный комбайн :). Не надо забивать саморезы в щкаф обратной стороной отвертки (ну или шуруповертом)) даже если вы мастер по забиванию гвоздей.

P.S. Ну и для успокоение — этот самый UNAS стоит в темном углу и на «боевые» системы особо не влияет 🙂

Комментарии запрещены.