Ну ладно, второй. О ней известно только то, что она web. Хорошо, если на PHP, но, в принципе, методика не отличается для любого скриптового некомпилируемого языка. Итак, мы не видим то, что должны видеть. Как это развидеть?
Для начала определяется место, где выводится то, что нам надо видеть. Обычно при этом просматривается код страницы, ищутся идентификаторы рядом с интересующим нас местом. Чем уникальнее, тем меньше мусора потом придется разгребать. Потом в дело вступает ее величество консоль. Дело в том, что там есть прекрасные инструменты, помогающие в быстром поиске. А они вам, уж поверьте, пригодятся. Современные веб-движки щеголяют десятками тысяч файлов, объединенными в неявную структуру, которую вы можете и не понимать. А баг надо искать здесь и сейчас, не перелопачивая тонны документации по движку. Поэтому заходим в консоль, переходим в папку web-движка и выполняем grep -rl '<найденные идентификаторы>' ./. Когда поиск завершится, вдумчиво всматриваемся в список и определяем, удачно ли мы выбрали точку поиска. Если найдено больше 20 файлов, значит, надо искать что-то более уникальное. Хотя бывает так, что по структуре движка сразу становится понятно, что твое, а что просто примазалось.
Если файлов не очень много и хочется еще сильнее сузить круг поисков, выполняем команду grep -ri '<найденные идентификаторы>' ./. Обратите внимание на ключ -i. Он не только найдет нам все файлы, в которых встречается то, что мы ищем, но и покажет строку, в которой это нашлось. И это прекрасно. Сразу можно выделить конкретный файл или файлы, в которых есть то, что нам необходимо. Теперь надо посмотреть, как и что выводится в том месте, в котором происходит какая-то фигня и искать файлы, в которых это встречается.
То есть вы поняли, да? Если исключить разбор кода в случае, когда необходимо понимать, как формируются данные для вывода, все обнаружение бага состоит из итеративного поиска по дереву исходников web-движка. При кажущейся примитивности способа, он достаточно эффективен для слепого поиска, то есть тогда, когда неизвестен ни движок, ни примерная дислокация проблемного кода. Ни даже язык, на котором написан движок. Обычно 3-4 итераций хватает, чтобы прибыть в какой-нибудь мелкий файлик в глубинах движка и узреть там страшное.
