Comments 13
Спасибо, очень любопытное расследование, было интересно почитать!
Про глубину тоже проблем и шагов. Я раньше ставил 5-15 бряк за рабочий день. Потом скилл вырос и ответственность и проекты, стал под 40-60 при дебагах.
В сегодняшние дни отчаянно ругаю ии, а бряк опять меньше :) надо было бы ругать людей?) жалко, что сейчас не лид. Цепочка запросов, требований решить что-то, починить от одного существа к другому. А всё наши гормоны! Из-за них!
Как будто прочитал детективный роман, за одним лишь исключением, что после первого прочтения всё стало ясно
*"Проблема явно в том, что вы не использовали switchMap, distinctUntilChanged и takeUntilDestroyed! 😤
Шутка. Но реально — история классная. Особенно про 'subscribe не срабатывает, но next() есть'. Это как получить смс 'дверь открыта', а приходишь — а замок сломан.
Так зачем нужно было изменять вери импортант анюзед Филд если оно действительно анюзед? Или оно как в анекдоте "швабры держат потолок"?
Ну, примерно так, да :)
Подозреваю, что раньше поле что-то меняло в шаблоне (например, стиль компонента при выделении/блюре). Подозреваю даже, что раньше метод напрямую из шаблона и вызывался. А потом этого стало недостаточно и кто-то добавил вызов этого метода на afterContentChecked, не заметив, что внутри таймаут создается.
Ну а потом шаблон изменился, компонент убрали, но метод не удалили, ведь он уже вызывался не только из шаблона, но и из хука, а значит он зачем-то нужен.
Точную историю, почему это поле осталось, я не знаю (и не буду смотреть по гит логу), но предположение выше вполне реалистичное
А не смотрели - этот баг поправили в следующих версиях ангулара? Я к тому - помогло ли бы обновление версии, что предлагалось в самом начале багфиксинга начальству? А то бывает так, что возлагается надежда на обновление - обновление производится (часто нужно покупать, и в любом случае оно не бесплатное, т.к. работа программиста), а на выхлопе ноль. Начальство обычно сильно бомбит от этого.
Чтобы точно ответить на этот вопрос, нужно обновить ангуляр и попытаться воспроизвести баг. Этого я, конечно, не делал.
Но я видел, что в последней версии код компонента совсем другой, и этих функций и вычисления вообще нет (или где-то в другом месте). Там полностью изменилась логика, поэтому сильно подозреваю, что этот баг не воспроизведется.
Нифига не понял, кроме того, что какое-то нафиг никому не нужное меню на каком-то неприметном сайте может жрать ресурсов больше, чем полноценное приложение
Не меню. Страница сайта. А проблема с меню была лишь внешним проявлением ошибки в компоненте.
Ну, кстати, не знаю, насколько много там ресурсов отжиралось. Скорее всего, не слишком много. Потому что никаких вычислений не было, просто бесконечные и очень частые вызовы функций. Если бы эти функции потребляли ресурсы, приложение просто зависло бы сразу. А оно работало быстро и отзывчиво, поэтому никто и не заметил проблему.
Но - да, этот опыт в том числе учит, что нужно всегда тестировать приложение на возможные проблемы с производительностью, чтобы не получить вот такое вот
Был недавно забавный баг.
Для понимания, мне дали задание сделать фото страницу в аврора ос. Она в свою очередь использует qt. С qt я сталкивался очень давно еще на 3 версиях, а с qml вообще не работал. Задание было сделать страницу камеры и компонент для вывода 3 фото. Между компонентом и страницей передаются фото через ListModel из самой страницы фото.
А баг заключался в том что если повторно открывать страницу с камерой, то приложение падало. У меня баг ни как не повторялся. Тестировщики его ловили постоянно. Видео мне записали. У себя проверял, все построчно отлаживал, не падает и все.
Так как хелпер для камеры был написан на cpp, то я подумал что qml(js) не может ронять приложение в segfault и полез разбираться в cpp. Там тоже не нашел в чем проблема.
Потом главный разработчик ушел в отпуск и мне пришлось собирать пакеты для тестирования на виртуалку и сами телефоны. Так как и это я делал в первый раз, то пакет для телефонов собрал криво и он не устанавливался. Пересобрал пакет и сразу проверил на своем телефоне. Так как я там для камеры сделал изменения, решил проверить камеру, что все изменения попали в собранный пакет. И тут решил проверить баг и он воспроизвелся на телефоне.
Да тестировщики обычно тестировали на виртуалках удаленно и там очень плохо была реализована работа с камерой, либо с веб камеры от пк подключать либо ролик. Все это дело очень плохо работает и отваливается постоянно.
После этого начал разбираться, почему падает. Баг смог воспроизвести, если пакет собран релизной версией, то падает, если в дебажной, то все работает. А где падает не понятно.
Взял приложение из примеров, там все работает, на основе него я и делал свою страницу. Взял другой пример, по сути все то же самое только настроек больше, все работает.
Шерстил код и тут заметил что к ListModel я обращаюсь по имени, а нужно еще класс указывать или как это называется в qml. Поправил обращение с указанием класса и все заработало.
Потом уже вспомнил, что когда-то давно тоже попадались баги релизной/дебажной сборки, но на сколько я помню тогда удалось победить его, указав сборку оптимизации другой.
самые неприятные баги – те, что воспроизводятся один раз из ста
Сталкивался с ситуацией, когда мало того, что баг редкий, так еще и воспроизводится только в проде на машинах, которые "забыли" на стенд тестирования поставить.
Старый добрый Хабр, как мы его любим. Спасибо.
История одного бага