Comments 6
третий тип багов я вот как-то не встречал, зато первый и второй — сколько угодно.
Один из таких «не доставляющих достаточно серъезных проблем, чтобы его нашли» в моей практике — утечка памяти при использовании камеры (на кадры выделялось чуть больше памяти, чем освобождалось). Т.к. утечка была порядка «килобайты в минуту», а камеру использовали редко — этот баг тоже ждал «своего разработчика» (где-то полгода наверно прошло, пока при добавлении какой-то фичи к камере, нашли эту утечку)
Один из таких «не доставляющих достаточно серъезных проблем, чтобы его нашли» в моей практике — утечка памяти при использовании камеры (на кадры выделялось чуть больше памяти, чем освобождалось). Т.к. утечка была порядка «килобайты в минуту», а камеру использовали редко — этот баг тоже ждал «своего разработчика» (где-то полгода наверно прошло, пока при добавлении какой-то фичи к камере, нашли эту утечку)
А как вам «640 кб хватит всем?». В одной навигационной программе было что-то вроде генератора путей для временных файлов. Сгенерированные строки хранились в массиве фиксированного размера, не помню для чего это было сделано, явно какая то оптимизация. А размер этого массива был порядка нескольких тысяч элементов. Все было хорошо, пока не прикрутили функцию скачивания информации о пробках. В итоге программа вылетала через несколько дней работы. Повезло, что тестировщики были хорошими — смогли выявить закономерность между включением пробок и вылетанием.
А незамеченной бага оставалась годами — мало кто не выключает навигатор сутками.
А незамеченной бага оставалась годами — мало кто не выключает навигатор сутками.
>Неиспользуемая глобальная переменная на 50 MB
Небось добавили, чтобы потом героически «оптимизировать программу».
Небось добавили, чтобы потом героически «оптимизировать программу».
Как-то раз обратились с проблемой — «ваша программа жрет процессор». У клиента был свежеустановленный Windows Server 2016 на железку с хорошими характеристиками для терминальной работы, однако наша система почему-то занимала в итоге чуть ли не все ресурсы сервера (3-5% на пользователя, итого на ~20 пользователей доходило до 100%). После долгих поисков выяснилось, что проблема заключается в том, что сторонний плагин при своей работе из-за ошибки в коде на каждый (!) контрол окна вешал таймер, и вот этот таймер грузил процессор. Интересно, что во всех предыдущих версиях Windows эти таймеры (а плагин без изменений работал лет 10) вообще никак себя не проявляли, проблема вылезла только на Windows Server 2016 и попутно на Windows 10. После перемещения ровно одной строчки в другое место кода (таймер должен был быть в строго определенных случаях на строго определенных контролах) вся загрузка сервера моментально снизилась до ожидаемых величин
Недавно занялся реверсом игр, уж очень хотелось посмотреть и поправить любимую игру (Geometry Wars). И даже являясь новичком случайно обнаружил в ней, что если побить рекорд и вписать своё имя, то игра будет вечно считывать длину строки, в каждом кадре, пока игру не перезапустят. Зачем вообще надо было считать строку, если можно было инкрементировать счётчик один раз и по нему добавить ноль в конце? Игра иногда подтормаживает, хотя очень простая для современных устройств, отчего ожидаю найти ещё больше багов.
Sign up to leave a comment.
Три примера багов, которые ни от кого не прячутся