Точка обнаружения программы отладки и источник ошибок
Обновлено: 05.07.2024
В этой главе представлен ряд функций компилятора, облегчающих анализ и отладку программы.
Параметры -Xlist предоставляют ценный способ анализа исходной программы на наличие несоответствий и возможных проблем во время выполнения. Анализ, выполняемый компилятором, является глобальным для всех подпрограмм.
–Xlist сообщает об ошибках выравнивания, согласования количества и типа аргументов подпрограммы, общего блока, параметра и различных других ошибок.
–Xlist также можно использовать для составления подробных списков исходного кода и таблиц перекрестных ссылок.
Программы, скомпилированные с параметрами -Xlist, автоматически встраивают данные анализа в двоичные файлы. Это позволяет осуществлять глобальную проверку программ по сравнению с программами в библиотеках.
5.1.1 Обзор GPC
Глобальная проверка программы (GPC), вызываемая параметром -Xlist x, выполняет следующие действия:
Применяет правила проверки типов Фортрана более строго, чем обычно, особенно между отдельно скомпилированными подпрограммами
Применяет некоторые ограничения переносимости, необходимые для перемещения программ между разными машинами или операционными системами
Обнаруживает допустимые конструкции, которые, тем не менее, могут быть неоптимальными или подверженными ошибкам
Выявляет другие потенциальные ошибки и неясности
В частности, глобальная проверка сообщает о таких проблемах, как:
Конфликты в количестве и типе фиктивных и фактических аргументов
Неверные типы значений функции
Возможны конфликты из-за несоответствия типов данных в общих блоках между разными подпрограммами
Функция, используемая в качестве подпрограммы, или подпрограмма, используемая в качестве функции
Объявленные, но неиспользуемые функции, подпрограммы, переменные и метки
Упомянутые, но не объявленные функции, подпрограммы, переменные и метки
Использование неустановленных переменных
Переменные неявного типа
Несоответствие именованных общих длин блоков, имен и макетов
5.1.2 Как вызвать глобальную проверку программы
Параметр -Xlist в командной строке вызывает глобальный анализатор программ компилятора. Существует ряд подопций, как описано в следующих разделах.
Пример: скомпилируйте три файла для базовой глобальной проверки программы:
В предыдущем примере компилятор:
Создает выходные списки в файле any1.lst
Компилирует и компонует программу, если нет ошибок
5.1.2.1 Вывод на экран
Обычно выходные списки, созданные -Xlist x, записываются в файл. Для отображения непосредственно на экране используйте -Xlisto для записи выходного файла в /dev/tty .
Пример: отображение на терминале:
5.1.2.2 Функции вывода по умолчанию
Опция –Xlist предоставляет комбинацию функций, доступных для вывода. Без других опций -Xlist по умолчанию вы получаете следующее:
Имя файла листинга берется из первого появившегося источника ввода или объектного файла с заменой расширения на .lst
Список источников с нумерацией строк
Сообщения об ошибках (встроенные в листинг) для несоответствий между подпрограммами
Таблица перекрестных ссылок идентификаторов
Разбиение на страницы по 66 строк на страницу и 79 столбцов на строку
Не расширять включаемые файлы
5.1.2.3 Типы файлов
Процесс проверки распознает все файлы в командной строке компилятора, которые заканчиваются на .f , .f90 , .f95 , .for , .F , .F95 или .o . Файлы .o предоставляют процессу информацию, касающуюся только глобальных имен, таких как имена подпрограмм и функций.
5.1.3 Некоторые примеры проверки -Xlist и глобальной программы
Вот список исходного кода Repeat.f, используемого в следующих примерах:
Пример: используйте -XlistX для отображения ошибок, предупреждений и перекрестных ссылок
5.1.4 Подопции для глобальной проверки между подпрограммами
Основной глобальный параметр перекрестной проверки — это -Xlist без дополнительных параметров. Это комбинация подпараметров, каждый из которых можно указать отдельно.
В следующих разделах описываются варианты создания списка, ошибок и таблицы перекрестных ссылок. В командной строке может отображаться несколько подопций.
5.1.4.1 Синтаксис подопций
Добавьте подопции в соответствии со следующими правилами:
Добавить подопцию к -Xlist .
Не ставьте пробела между -Xlist и подпараметром.
Используйте только одну подопцию для -Xlist .
5.1.4.2 -Xlist и его подопции
Объединяйте подпараметры в соответствии со следующими правилами:
Наиболее общий вариант — -Xlist (список, ошибки, таблица перекрестных ссылок).
Конкретные функции можно комбинировать с помощью -Xlistc , -XlistE , -XlistL или -XlistX .
Другие подпараметры содержат дополнительные сведения.
Пример: каждая из этих двух команд выполняет одну и ту же задачу:
В следующей таблице показаны отчеты, сгенерированные только этими базовыми подпараметрами -Xlist:
Ошибки, список, перекрестная ссылка
–Xсписок E
Только ошибки и список источников
–Xсписок L
Только таблицы ошибок и перекрестных ссылок
–Xсписок X
Только ошибки и график вызовов
–Xlist c
В следующей таблице показаны все подпараметры -Xlist.
–Xlist (без подпараметра)
Показывает ошибки, список и таблицу перекрестных ссылок
–Xlist c
Показывает графики вызовов и ошибки
При использовании отдельно -Xlistc не показывает список или перекрестную ссылку. Он создает граф вызовов в виде дерева с использованием печатных символов. Если некоторые подпрограммы не вызываются из MAIN, отображается более одного графика. Каждый BLOCKDATA печатается отдельно без связи с MAIN .
По умолчанию график вызовов не отображается.
–Xсписок E
При использовании отдельно параметр -XlistE показывает только межпрограммные ошибки и не показывает список или перекрестную ссылку.
–Xlist ошибка [ nnn ]
Подавляет ошибку nnn в отчете о проверке
Используйте -Xlisterr, чтобы скрыть пронумерованное сообщение об ошибке из списка или перекрестной ссылки.
Например: -Xlisterr338 подавляет сообщение об ошибке 338. Чтобы подавить дополнительные определенные ошибки, используйте этот параметр несколько раз. Если nnn не указан, все сообщения об ошибках подавляются.
–Xlist f
Производит вывод быстрее
Используйте -Xlistf для создания списков исходных файлов и отчета о перекрестной проверке, а также для проверки источников без полной компиляции.
–Xlist h
Показывает ошибки перекрестной проверки остановки компиляции
С -Xlisth компиляция останавливается, если во время перекрестной проверки программы обнаруживаются ошибки. В этом случае отчет перенаправляется на стандартный вывод вместо файла *.lst.
–Xсписок I
Списки и перекрестные проверки включают файлы
Если используется только подпараметр -XlistI, включаемые файлы отображаются или сканируются вместе со стандартным выводом -Xlist (нумерованный список строк, сообщения об ошибках и таблица перекрестных ссылок).
По умолчанию включаемые файлы не отображаются.
–Xсписок L
Показывает список и ошибки
Используйте -XlistL для создания только списка и списка перекрестных ошибок. Эта подопция сама по себе не показывает таблицу перекрестных ссылок. По умолчанию отображается список и таблица перекрестных ссылок
–Xlist l n
Устанавливает разрывы страниц
Используйте -Xlistl, чтобы установить длину страницы, отличную от размера страницы по умолчанию. Например, -Xlistl45 устанавливает длину страницы в 45 строк. По умолчанию 66.
При n =0 ( -Xlistl0) этот параметр показывает списки и перекрестные ссылки без разрывов страниц для более удобного просмотра на экране.
(SPARC) Проверка согласованности директив OpenMP
Используйте -XlistMP, чтобы сообщить о любых несоответствиях в директивах OpenMP, указанных в файле исходного кода. Дополнительные сведения см. также в Руководстве пользователя OpenMP API.
–Xlist или имя
Укажите выходной файл отчета -Xlist
Используйте -Xlisto, чтобы указать сгенерированный выходной файл отчета. (Пробел между o и именем обязателен.) При использовании -Xlisto name вывод осуществляется в имя, а не в файл .lst .
Для отображения непосредственно на экране используйте параметр: -Xlisto /dev/tty
–Xсписок
Подавляет несвязанные символы из перекрестных ссылок
Используйте -Xlists для исключения из таблицы перекрестных ссылок любых идентификаторов, определенных во включаемых файлах, но не упомянутых в исходных файлах.
Эта подопция не действует, если используется подопция -XlistI.
–Xlist v n
Устанавливает уровень «строгости» проверки
n равно 1,2 , 3 или 4 . По умолчанию 2 ( –Xlistv2 ):
Показывает проверенную информацию обо всех именах только в сводной форме, без номеров строк. Это самый низкий уровень строгости проверки — только синтаксические ошибки.
Показывает перепроверенную информацию со сводками и номерами строк. Это уровень проверки строгости по умолчанию, включающий ошибки несогласованности аргументов и ошибки использования переменных.
Показывает перекрестную проверку со сводками, номерами строк и картами общих блоков. Это высокий уровень строгости проверки, включающий ошибки, вызванные неправильным использованием типов данных в общих блоках в разных подпрограммах.
Показывает перекрестную проверку со сводками, номерами строк, картами общих блоков и картами блоков эквивалентности. Это самый строгий уровень проверки с максимальным обнаружением ошибок.
–Xlist w [nnn]
Устанавливает ширину строк вывода
Используйте -Xlistw для установки ширины строки вывода. Например, -Xlistw132 устанавливает ширину страницы в 132 столбца. По умолчанию 79.
–Xlist война [ nnn]
Подавляет предупреждение nnn в отчете
Используйте -Xlistwar для подавления определенного предупреждающего сообщения из выходных отчетов. Если nnn не указан, то все предупреждающие сообщения не печатаются. Например, -Xlistwar338 подавляет предупреждающее сообщение номер 338. Чтобы подавить более одного, но не всех предупреждений, используйте этот параметр несколько раз.
–Xсписок X
Показывает только таблицу перекрестных ссылок и ошибки
-XlistX создает таблицу перекрестных ссылок и список ошибок кросс-процедур, но не список источников.
Некоторые параметры компилятора полезны для отладки. Они проверяют индексы, обнаруживают необъявленные переменные, показывают этапы последовательности компиляции, отображают версии программного обеспечения и т. д.
Компоновщик Solaris имеет дополнительные средства отладки. См. ld (1) или введите команду ld –Dhelp в командной строке, чтобы просмотреть онлайн-документацию.
5.2.1 Границы нижнего индекса ( –C )
Если вы компилируете с параметром -C , компилятор добавляет проверки во время выполнения на наличие ссылок за пределами границ каждого нижнего индекса массива и соответствие массива. Это действие помогает выявить некоторые ситуации, вызывающие ошибки сегментации.
Пример: Индекс вне допустимого диапазона:
5.2.2 Необъявленные типы переменных ( –u )
Опция -u проверяет наличие необъявленных переменных.
Опция -u приводит к тому, что все переменные изначально идентифицируются как необъявленные, поэтому все переменные, которые не объявлены явно операторами типа или оператором IMPLICIT, помечаются ошибкой. Флаг -u полезен для обнаружения переменных с ошибками. Если установлен параметр -u, все переменные считаются необъявленными до тех пор, пока не будут явно объявлены. Использование необъявленной переменной сопровождается сообщением об ошибке.
5.2.3 Проверка версии компилятора ( –V )
Опция –V приводит к отображению имени и идентификатора версии каждой фазы компилятора. Этот параметр может быть полезен для отслеживания происхождения неоднозначных сообщений об ошибках и отчетов об ошибках компилятора, а также для проверки уровня установленных исправлений компилятора.
Sun Studio предоставляет тесно интегрированную среду разработки для отладки приложений, написанных на языках Fortran, C и C++.
Программа dbx обеспечивает управление событиями, контроль процессов и проверку данных. Вы можете наблюдать за тем, что происходит во время выполнения программы, и выполнять следующие задачи:
Исправьте одну подпрограмму, затем продолжите выполнение без перекомпиляции остальных
Установить точки наблюдения для остановки или отслеживания при изменении указанного элемента
Сбор данных для настройки производительности
Отслеживание переменных, структур и массивов
Установите точки останова (установите места остановки в программе) в строках или в функциях
Показывать значения — после остановки показывать или изменять переменные, массивы, структуры
Пошаговое выполнение программы, один источник или сборочная линия за раз
Трассировка хода выполнения программы — отображение последовательности принятых вызовов
Вызов процедур в отлаживаемой программе
Перешагнуть или перейти к вызову функции; шаг вперед и назад из вызова функции
Запустить, остановить и продолжить выполнение на следующей строке или на другой строке
Сохраните, а затем воспроизведите весь или часть отладочного запуска
Изучите стек вызовов или перемещайтесь вверх и вниз по стеку вызовов
Скрипты программы во встроенной оболочке Korn
Следите за программами по мере их ветвления (2) и выполнения (2)
Для отладки оптимизированных программ используйте команду dbx fix, чтобы перекомпилировать подпрограммы, которые вы хотите отладить:
Скомпилируйте программу с соответствующим уровнем оптимизации -O n.
Начать выполнение под dbx .
Используйте fix -g any .f без оптимизации процедуры, которую вы хотите отладить.
Используйте continue с этой скомпилированной подпрограммой.
Некоторые оптимизации будут запрещены наличием -g в команде компиляции. Подробнее см. в документации по dbx.
Для получения дополнительной информации см. руководство Sun Studio "Отладка программы с помощью dbx" и справочные страницы dbx (1).
Отладка в рабочей среде всегда была тем, чего мы стараемся избегать, используя несколько этапов контроля качества, промежуточные среды и автоматизацию для устранения ошибок в рабочей среде.
Несмотря на это, иногда ошибка попадает в рабочую среду, и когда это происходит, нам нужна стратегия, чтобы справляться с ней безопасно и эффективно.
Прошли те времена, когда у вас была ошибка в рабочей среде, вы сообщали о ней и воспроизводили ее на этапе подготовки или разработки. Современные инструменты отладки теперь позволяют безопасно и надежно отлаживать производственную среду, не отвлекая пользователей и не вызывая простоев.
Безопасно ли выполнять отладку в рабочей среде?
Один из основных вопросов, волнующих людей, — это безопасность отладки в рабочей среде? Ответ на этот вопрос заключается в том, что это возможно.
Определенные методы отладки, такие как удаленный отладчик в вашей среде IDE или выдача информации об ошибках пользователю, не считаются безопасными.
Другие методы, такие как ведение журнала, захват контекста ошибки и отладчики, специально предназначенные для рабочей среды, могут использоваться с разным уровнем успеха.
Что делает отладку в рабочей среде безопасной?
Если вам нужно выполнить отладку в рабочей среде, при этом нужно убедиться в следующем.
- Отладка не сильно влияет на производительность.
- Отладка не мешает людям использовать ваше приложение.
- Защищенные данные не доступны внешнему миру.
- Вы получаете достаточно отладочной информации, чтобы найти и устранить проблему как можно скорее.
Первые 3 пункта говорят сами за себя, когда отладка необходима для бесперебойной работы приложения и обеспечения безопасности процесса.
Получить всю необходимую информацию при возникновении проблемы может быть сложно, но в зависимости от сложности/серьезности проблемы это может иметь решающее значение.
При отладке вы хотите получить как можно больше информации о проблеме за минимально возможное время. Если вам приходится переключаться между несколькими системами и повторять ошибки несколько раз, чтобы исправить ошибки, это только усугубит стресс, связанный с решением критической проблемы.
Почему использование удаленного отладчика в рабочей среде не является хорошей идеей?
При использовании этих подключений отладчика вы должны поместить JVM в режим отладки, что может иметь огромное влияние на производительность по сравнению с отсутствием этой возможности отладки.
Предположим, что у вас еще не настроено соединение с отладчиком, вам также потребуется перезапустить Java, чтобы установить это соединение. Это не то, чем вы хотите заниматься в и без того стрессовой ситуации.
При попадании в точку останова весь механизм Java останавливается, при срабатывании точки останова все потоки в механизме приостанавливаются. Следовательно, ваше приложение становится непригодным для использования, пока вы не прекратите отладку.
Почему выдавать пользователю информацию об ошибках — плохая идея?
Если у вас есть ошибка, выдача всей этой информации пользователю и ее исправление через службу поддержки кажется хорошим решением; однако вы должны быть осторожны с отображаемой информацией.
Трассировка стека на странице с ошибкой может выглядеть не очень красиво, но может указать на проблему, а данные, содержащиеся в трассировке стека, обычно безопасны. В этой трассировке может быть что-то, что вы не хотите, чтобы пользователь видел.
Сброс переменных, таких как пользовательские данные или информация запроса/ответа, для предоставления вам большего контекста может нести больший риск, поскольку он может содержать такие данные, как заголовки авторизации, информацию о безопасности и личные данные, которые могут сделать вашу систему уязвимой.
Как использовать ведение журнала для отладки в рабочей среде
Долгое время вход в рабочую среду для отладки ошибок был отраслевым стандартом, а такие инструменты, как Splunk, Elastic или Papertrail, упрощали эту задачу.
С помощью ведения журнала вы можете фиксировать данные о любых ошибках, чтобы у вас был контекст при их возникновении. В некоторых языках, таких как Node JS или PHP, вы можете добавить ведение журнала во время выполнения, хотя это сопряжено с определенным риском, в таких языках, как Java, это не всегда возможно.
Если вы полагаетесь на ведение журналов, всегда лучше делать это при разработке приложения и использовать соответствующие уровни журналов, чтобы не возникало потока журналов во время обычной работы.
Если произошла ошибка, а данных недостаточно, вы можете добавить необходимые журналы для этой ошибки, чтобы получить нужный контекст.
- При этом необходимо учитывать некоторые моменты.
- Добавление дополнительного журнала может потребовать перезапуска приложения.
- Объем ведения журнала может стать чрезмерным и сложным для управления
- Выявление ошибок может быть проблематичным, если они скрыты среди других сообщений.
Лучшая альтернатива регистрации в рабочей среде?
В 2014 году в качестве продукта была представлена концепция неблокирующих отладчиков. Концепция этих отладчиков заключается в захвате стека и переменных при возникновении такого события, как ошибка, без блокировки выполнения кода.
Это дает вам представление о том, что происходит при возникновении ошибки, поэтому вы автоматически получаете полный контекст ошибки. Собранные данные позволяют выявить первопричину проблемы, не останавливая выполнение кода и не требуя дополнительного ведения журнала, инструментов отладки или влияния на производительность.
Неблокирующие отладчики отлично подходят для отладки более простых проблем, когда основная причина ошибки находится на вершине стека. Если ошибка не на вершине стека, может потребоваться дальнейшая отладка, но у вас будет гораздо лучше, чем то, где на самом деле находится основная причина ошибки.
FusionReactor предоставляет решение под названием «Снимок события». При возникновении ошибки автоматически фиксируются код нарушения, полный стек и переменные, чтобы вы могли найти и исправить свои ошибки без необходимости какой-либо ручной работы по диагностике причины ошибки. ошибка.
Могу ли я использовать пошаговый отладчик в рабочей среде?
Ранее в блоге я упоминал, что использование удаленного отладчика, подобного включенному в вашу IDE, на рабочих машинах небезопасно, но есть ли альтернатива этому, которая позволяет вам пошагово устранять ошибки?
Некоторые пошаговые отладчики специально предназначены для работы в производственной среде, поэтому вы можете приостанавливать код, выполнять пошаговые действия и наблюдать за изменениями состояния, не затрагивая пользователей вашего приложения.
Это достигается за счет ограничения отладки одним потоком приложения, а не остановки всего ядра, и использования комбинации условий, чтобы не блокировать потоки в работе там, где это не нужно.
Например, вы можете установить точку останова с условиями для отладки только в том случае, если переменная не была установлена, или только для определенных учетных записей, при срабатывании точки останова вы можете установить тайм-аут, чтобы поток был освобожден через заданный период времени.
В некоторых случаях, когда у вас есть серьезная или сложная ошибка и вы хотите быстро диагностировать причину, блокировка отдельного потока или пользователя на короткий период времени позволяет провести диагностику, которая обеспечит бесперебойную работу вашего приложения. исправить, чтобы не прерывать пользователя.
FusionReactor предоставляет такой отладчик, в котором вы можете установить точку останова при срабатывании исключения, при входе в метод или на определенной строке кода. Условия позволяют вам настроить точку останова, чтобы вы могли отладить проблему, в то время как остальная часть вашего приложения работает в обычном режиме.
Как выполнять отладку в производственной среде — краткое изложение
Раньше люди активно избегали отладки в рабочей среде, но из-за быстро растущей сложности приложений и окружающих их сред программное обеспечение сейчас находится на таком этапе, что это уже невозможно.
Несмотря на то, что некоторые методы отладки, такие как подключение к IDE, определенно не рекомендуются, существуют надежные и безопасные способы отладки рабочей проблемы.
Вход в производственную среду даст вам нужные результаты, но может потребоваться время, чтобы получить правильные результаты, а также потребуется перезагрузка до двух.
Внедрение новых технологий, которые помогают автоматически выполнять отладку в рабочей среде путем захвата контекста, — это то, что мы должны использовать в наших средах, чтобы больше не бояться проблем в рабочей среде.
FusionReactor — это один из таких инструментов, который вам следует включить в свою среду с бесплатной двухнедельной пробной версией
Я хотел бы поделиться с вами своим повседневным советом по отладке, который делает мою жизнь намного проще. Если вы обнаружили, что ваш собственный совет не указан здесь, пожалуйста, прокомментируйте его, чтобы он мог принести пользу большему количеству людей здесь 🙂
Для демонстрации я воспользуюсь простым примером. Введите недопустимое имя в SE38 и нажмите кнопку отображения. Внизу отображается сообщение. Я покажу вам, как найти точную строку кода, которая вызывает эту информацию.
примечание: некоторые из перечисленных здесь подходов могут оказаться неэффективными именно в этом случае, я просто перечисляю здесь все свои советы для полноты картины. Я верю, что каждый совет может быть полезен в определенном случае.
нажмите на зеленую иконку, и мы найдем идентификатор класса сообщения: DS, номер 017
SE91, использовать, где использовать список:
Ой, так много просмотров…
Затем мне приходится вручную фильтровать их один за другим, чтобы найти правильный. Дважды щелкните один за другим. Я игнорирую все записи с типом MESSAGE E, так как в моем случае тип сообщения не E, а S. Через одну минуту я подтверждаю, что пытаюсь найти следующее сообщение.
да, это подтверждается отладкой:
Вывод: недостатком A1 является то, что, как вы видите, если есть много результатов, в которых используется список, скажем, сто, вам все равно потребуется некоторое время, чтобы вручную найти правильный.
введите /h в области команд и нажмите кнопку отображения, чтобы запустить отладчик.
Создайте точку наблюдения с двумя указанными ниже условиями. После этого нажмите F8, отладчик автоматически остановится на нужной вам строке. Этот подход занял у меня всего 20 секунд, чтобы закончить работу.
Подробный снимок экрана о том, как создать точку наблюдения в отладчике, см. на рисунке, предоставленном Джимом Таскером:
Как переключиться в режим отладки для модального (всплывающего) окна
Поскольку командная строка недоступна, если задействовано модальное окно (всплывающее окно), в этом случае обратитесь к SAP-ноте 118184 о том, как переключиться в режим отладки, или обратитесь к этой вики.
Запустите отладчик точно так же, как A2, создайте динамическую точку останова с помощью команды ABAP = MESSAGE. Отладчик снова остановится на правильной строке.
При таком подходе я снова потратил всего 20 секунд.
Или вы можете использовать меню через Точки останова->Точка останова в->Точка останова в сообщениях для достижения того же результата.
Вывод: если сценарий, который вы хотите отладить, достаточно сложный, например, глубокий стек вызовов с несколькими задействованными компонентами, отладчик может часто останавливаться на коде ABAP с ключевым словом MESSAGE. Вы по-прежнему должны вручную проверять, является ли код именно тем, который вы ищете на каждой остановке. Однако это все же намного эффективнее, чем отлаживать вручную по одному.
Tcode SE93, найдите имя пакета SE38:
Затем используйте отчет RS_ABAP_SOURCE_SCAN и сохраните указанные ниже критерии поиска. Причина, по которой я не использую имя программы RSABAPPROGRAM, заключается в том, что это просто отчет-оболочка. Реальная реализация SE38 в него не входит.
У нас есть только 4 результата.
Вы можете использовать альтернативный tcode CODE_SCANNER, который может дать тот же результат:
С моей точки зрения, мне нравится этот формат A4. Я не могу вспомнить, сколько раз это помогало мне в моей отладочной жизни. Более того, он будет использоваться не только как совет по отладке, но и как один из способов изучения чужого кода. Предположим, вам интересно, как определенная функция реализована программным компонентом. Это хорошая отправная точка, чтобы придумать осмысленное ключевое слово для поиска, указать пакет этого программного компонента и углубиться в код результата.
tcode SAT, создайте новый вариант, убедитесь, что выбран элемент переключателя «Агрегация — нет».
Затем запустите SE38 в SAT, нажав кнопку «Выполнить».
повторите свои действия как обычно – введите несуществующий отчет и нажмите кнопку отображения, чтобы увидеть сообщение. После этого нажмите кнопку «Назад» или «Выход» в SE38. SAT автоматически откроется, чтобы показать вам всю информацию о трассировке во время выполнения. Это займет некоторое время — вы можете увидеть информацию о ходе выполнения внизу:
перейдите на вкладку «Иерархия вызовов», нажмите кнопку «Найти». Оператор ввода = СООБЩЕНИЕ и вперед. Вы увидите два результата поиска.
дважды щелкните строку списка совпадений, и вы увидите исходный код.
Вывод: если сценарий, который вы отслеживаете с помощью SAT, сложный, вы получите огромный файл трассировки.Хотя вы можете указать чрезвычайно большой размер файла трассировки, согласно моему реальному опыту, вы не сможете открыть результирующий файл трассировки, когда он превысит 1 ГБ, по крайней мере, на моем сервере приложений.
Сначала вы открываете SE38, вводите неверное имя программы.
Откройте второй сеанс, включите ST05 с настройками по умолчанию.
Вернитесь в окно SE38, нажмите кнопку отображения.
Вернитесь к трассировке ST05, деактивируйте и отобразите результат трассировки:
Мы знаем, что в таблице PROGDIR хранится информация заголовка отчета. Для ABAP-редактора имеет смысл проверять правильность имени программы путем поиска в этой таблице, не так ли? Так что несомненным следующим шагом будет выдача сообщения в случае неудачного поиска по базе данных. Нажмите кнопку «Отобразить местоположение вызова ABAP», чтобы перейти к исходному коду:
Мы видим, что логика заключается в том, что сначала попробуйте выполнить поиск в БД с неактивной версией, а если не удастся, попробуйте с активной версией.
Поэтому мы надеемся, что код, который мы пытаемся найти, находится в непосредственной близости от оператора SQL в строках 774 и 779. К счастью, в данном случае да, он находится в строке 813.
Если сообщение создается не в SAP GUI, а в пользовательском интерфейсе веб-клиента ABAP webdynpro или CRM, все эти шесть подходов по-прежнему работают.
В этом блоге основное внимание уделяется тому, как эффективно найти исходный код, в котором возникает сообщение, в среде CRM Webclient UI.
Использование SAT для отслеживания веб-приложений
Подход 5 хорошо использует мощный инструмент SAT. Имейте в виду, что SAT может не только отслеживать транзакции, выполняемые в SAP GUI, но и работать с веб-приложением. Для получения более подробной информации прочитайте этот замечательный документ «Измерение производительности и анализ транзакции веб-интерфейса с использованием SE30» от Bhushan Dharmik.
Эти блоги/вики не рассказывают о специальном решении для поиска места отправки сообщений, но содержат общие советы, которые ускорят отладку и облегчат вашу жизнь.
Устранение незнакомой проблемы ABAP, Ноэль Коннолли
Три способа достижения условной точки останова в вашей ABAP-программе — спросили мои коллеги, поэтому я пишу 🙂
Как использовать точку останова с типом исключения — реальный пример
Этот совет имеет ту же логику, что и Approach3, с той лишь разницей, что используется другой тип точки останова ABAP.
Как эффективно отлаживать приложения ERP и CRM
Когда я новичок в CRM и мне нужно отлаживать приложение бизнес-транзакций CRM для разрешения сообщения о заявке, я чувствовал себя очень разочарованным, поскольку, хотя я использовал ВСЕ ШЕСТЬ подходов, описанных здесь, точка останова не могла быть активирована 🙁 Наконец Я понял, что просто работает, как задумано. Я делюсь с вами своими советами, полученными в ходе мучительной отладки в этой области, и надеюсь, что они будут вам полезны.
В своей предыдущей работе мне приходилось бороться с некоторыми сложными случаями, когда я вообще не знал, как начать отладку. A6, который я называю «оружием ST05», не позволяет мне работать до поздней ночи. Даже для самого сложного приложения я могу включить ST05, снова повторить приложение и проанализировать результат трассировки, чтобы определить, какая строка полезна для начала отладки. Так что мне нравится это универсальное средство. Вы можете сказать, что не помогло бы полное отсутствие доступа к базе данных для отлаживаемого приложения. Ну, я бы сказал, что это было бы редким случаем, по крайней мере, в моей собственной рабочей области.
Есть ли у вас дополнительные советы, не вошедшие в эту статью? Пожалуйста, поделитесь с нами 🙂
Распространенная проблема для Scratchers — когда скрипт, который может показаться безупречным, в итоге не выполняет ожидаемого или выделяется красным цветом (в версии 1.4). Обычно это обычные человеческие ошибки, которые можно исправить. Это широко известно как отладка, термин для которого был популяризирован в 20-м веке, когда Грейс Хоппер, ученый-компьютерщик, удалила настоящую мотылька из машины и сказала, что она "отлаживает машину". [1] [2]
Содержание
Проверка скриптов
Проверка неработающего скрипта часто бывает непростой задачей. Найти проблему в сценарии сложно, потому что это имеет смысл для автора. Часто мышление с точки зрения компьютера выявляет проблему.Например, чтобы найти сумму дробей 1/2+1/3+1/4+…+1/100, можно использовать следующий скрипт:
Это не сработает, поскольку при проверке скрипта переменная "n" будет равна 0 на последней итерации (цикл/повтор), что вызовет ошибку деления на ноль.
Другие проблемы могут возникать, когда действия выполняются, но не видны пользователю. Например, если спрайт скрыт или имеет призрачный эффект 100. Практический пример — продолжение сценария выше:
Сценарий просто скажет "Не так уж и здорово", потому что предыдущие два действия происходят за доли секунды, а иногда и за один цикл рендеринга оценщика. Чтобы устранить эти проблемы, используйте либо блок wait () секунд в разделе «Управление» между блоками, либо вместо него используйте блок say () for () секунд.
Иногда ошибка чисто логическая и кажется разумной только в данный момент. Часто их труднее всего отследить, потому что истинной «ошибки» не существует. Например, если случайно вставить неправильную переменную или изменить порядок вычитания, скрипт испортится без следа. Лучший способ найти эти ошибки — спросить друга. Пройдите всю программу блок за блоком и убедитесь, что выбранный друг понимает каждый шаг. Если есть логическая ошибка, они, вероятно, поймают ее.
Предотвращение ошибок
- Лучший способ предотвратить глупые ошибки — создать аккуратный и организованный код. Упорядочивание скриптов по их функциям или порядку оценки поможет найти ошибки и предотвратить их.
- Оставлять комментарии везде, где над сценарием было потрачено много времени; таким образом, если он снова сломается, к ним можно будет вернуться, чтобы увидеть, как скрипт работал в прошлом. Любой человек с достаточным опытом должен понять сценарий с первого взгляда.
- Не копируйте вслепую сценарии из других проектов, если это не было целью проекта. Если не считать моральных проблем с кражей копий, скорее всего, сценарий не будет работать в контексте программы. Чтобы узнать, как создавать простые интегрируемые инструменты, см. статью Расширенное использование клонов.
Проверка значений
Если необходимо знать значение, чтобы определить, работает ли скрипт, есть несколько способов найти его.
Использование блока Say(). Блок say можно использовать для постоянной проверки значения.
Обновление переменной. Переменная также может постоянно обновляться.
Эти методы также можно использовать для проверки логического значения:
Тестирование кода
Тестировать большой и сложный проект сложно, потому что любое изменение может привести к поломке.
Часто лучший способ — просто запускать проект снова и снова. Однако большие игры или анимацию было бы сложно отлаживать таким образом. Вместо этого введите определенные тестовые коды, которые могут быть удалены в финальной версии. Например, чтобы протестировать 27-й уровень игры, добавьте сценарий, в котором при нажатии пробела игра переходит на следующий уровень.
Чтобы убедиться, что код остается работоспособным, автоматизируйте определенные тесты. Например, скрипты, которые должны возвращать числовой ответ, могут быть автоматически протестированы в некоторых встроенных случаях:
Добавление ожиданий и отображение переменных
Способ отладки скриптов заключается в добавлении ожиданий и отображении переменных, чтобы все можно было увидеть шаг за шагом.
Список отладки
Также может помочь создание списка отладки и пошаговая печать. Не существует лучшего способа отладки журнала. Например, в приведенном выше примере сложения дробей:
Для записи переменных N и Total в список можно добавить блоки Debug, Add to list:
Распространенные причины ошибок
Неверные операции
Часто скретчеры пишут программы со сценарием, подобным следующему:
Этот скрипт вызовет ошибку после 10-го повторения блока навсегда, когда x = 0, так как в Scratch 1.4 ничего нельзя делить на 0. (Деление на ноль математически возвращает «неопределенное» или «нет решения», в то время как программно оно возвращает ошибку или «NaN».) Когда это происходит, сценарий будет выделен красным, а блок ()/() станет красным. Чтобы противостоять этой ошибке, лучше всего начать с x = 10,0001, а не с 10. Таким образом, x никогда не достигнет 0, он достигнет 0,0001 и -0,9999.
Аналогичные проблемы возникают с квадратными корнями, логарифмами и тригонометрическими функциями:
Порядок команд
Самая распространенная проблема со скретчерами — неправильное расположение команд. Например, чтобы спрайт бросился на другой спрайт, скретчер использует команды:
но это не похоже на то, что спрайт делает выпад.
Хорошим решением этой проблемы является простое перемещение команд до тех пор, пока скрипт не заработает. Например, чтобы заставить спрайт сделать выпад, Скретчер перемещает команду «указать в направлении 90» сразу после команды «подождите 0,5 секунды», таким образом, спрайт выглядит так, как будто он делает выпад:
Время
Еще одна распространенная проблема со скретчерами – синхронизация команд.Это часто можно увидеть в проектах, которые включают 2 сценария, взаимодействующих без трансляций или переменных, например, в примере проекта Joke. Когда сроки не идеальны, весь проект может быть брошен. Но не волнуйтесь, вот несколько способов решить эту проблему:
Трансляции и переменные
Использование трансляций и переменных позволит сценариям координироваться друг с другом. Трансляции включают в себя шляпные блоки, поэтому будьте готовы к большому количеству сценариев. Использование переменных сохранит скрипты. Если в таком проекте, как Joke, используются переменные, скорее всего, будет использоваться блок «ждать до». В противном случае вместо этого можно было бы использовать блок «если» или, возможно, блок «повторять до». В любом случае сценарии будут более точно согласованы.
Точное время
Если по какой-либо причине трансляции или переменные крайне нежелательны, количество времени между блоками можно настроить с помощью блока "wait() secs". Это было бы легко для такого проекта, как Joke, но не для сложной игры.
Повторяющийся процесс
Этот метод в основном подходит для очень сложных игр. Для точного обнаружения тесты следует повторить несколько раз, прежде чем активировать реакцию. Это может быть незаметно, но для запуска команды требуется небольшое количество времени. Если тестовый блок повторяется, это дает обнаружению немного больше времени, чтобы измениться. Пример этого можно найти в этом проекте.
Таймер
Блоки также могут вращаться вокруг таймера. Таймер Scratch можно сбрасывать и манипулировать им, так что с его помощью можно многое сделать.
Несовместимость
Третья и наименее распространенная причина, по которой скрипты не работают, заключается в том, что команды просто не работают друг с другом. Когда это произойдет, скрипт будет выделен красным цветом. Спрайт "в тупике". В этом случае с этим действительно ничего не поделаешь, кроме как полностью перестроить скрипт с другим подходом.
Устаревшие блоки
При использовании старых версий Scratch блоки могут быть помечены как "устаревшие!". Обычно это блоки в более новых версиях Scratch, которые несовместимы со старыми версиями. Использование этих блоков в старых версиях часто приводит к сбою скрипта.
Блоки типа "ничего не говорить" скрыты в Scratch 1.4, но не вызывают ошибки скрипта.
Что касается отладки JavaScript, чем быстрее, тем лучше. Вот наши главные советы по более быстрой и эффективной отладке.
Быстрее отлаживать JavaScript
Знание своих инструментов может иметь большое значение, когда дело доходит до достижения цели. Несмотря на репутацию языка JavaScript как сложного для отладки, если вы держите в рукаве несколько хитростей, устранение ошибок и ошибок займет меньше времени.
Мы составили список из 16 советов по отладке, которые вы, возможно, не знаете, но, возможно, захотите запомнить, когда в следующий раз вам понадобится отлаживать код JavaScript!
Большинство этих советов относятся к Chrome и Firefox, хотя многие из них также применимы и к другим инспекторам.
1. отладчик
После console.log отладчик — мой любимый инструмент быстрой и грязной отладки. Если вы поместите отладчик; строку в вашем коде, Chrome автоматически остановится там при выполнении. Вы даже можете обернуть его в условные операторы, чтобы он выполнялся только тогда, когда вам это нужно.
2. Отображать объекты в виде таблицы
Иногда у вас есть сложный набор объектов, которые вы хотите просмотреть. Вы можете либо использовать console.log и прокрутить список, либо запустить хелпер console.table. Так легче увидеть, с чем вы имеете дело!
3. Попробуйте все размеры
Хотя иметь все мобильные устройства на рабочем столе было бы здорово, в реальном мире это невозможно. Как насчет изменения размера окна просмотра? Chrome предоставляет вам все, что вам нужно. Перейдите в свой инспектор и нажмите кнопку переключения режима устройства. Смотрите, как оживают ваши медиа-запросы!
5. Сравните циклы с помощью console.time() и console.timeEnd()
Было бы очень полезно точно знать, сколько времени потребовалось для выполнения того или иного действия, особенно при отладке медленных циклов. Вы даже можете настроить несколько таймеров, назначив методу метку. Давайте посмотрим, как это работает:
6. Получить трассировку стека для функции
Вероятно, вы знаете, что JavaScript-фреймворки быстро создают много кода.
У вас будет много просмотров и много событий, поэтому в конечном итоге вы столкнетесь с ситуацией, когда захотите узнать, что вызвало конкретный вызов функции. Поскольку JavaScript не очень структурированный язык, иногда бывает сложно получить представление о том, что и когда произошло. Это тот случай, когда console.trace (или просто трассировка в консоли) пригодится для отладки JavaScript. Представьте, что вы хотите увидеть всю трассировку стека для вызова функции funcZ в экземпляре автомобиля в строке 33:
Строка 33 выведет:
Теперь мы видим, что func1 вызвала func2, которая вызвала func4. Затем Func4 создал экземпляр Car, а затем вызвал функцию car.funcX и так далее. Даже если вы думаете, что хорошо знаете свой сценарий, это все равно может быть весьма полезным. Допустим, вы хотите улучшить свой код. Получите трассировку и большой список всех связанных функций. Каждое из них кликабельно, и теперь вы можете переключаться между ними. Это похоже на меню только для вас.
7. Деминификация кода как простой способ отладки JavaScript
Иногда у вас может возникнуть проблема в производственной среде, и ваши исходные карты не дойдут до сервера. Не бойтесь. Chrome может преобразовывать ваши файлы Javascript в более удобочитаемый формат. Код не будет таким полезным, как ваш реальный код, но, по крайней мере, вы сможете увидеть, что происходит. Нажмите кнопку <> Pretty Print под средством просмотра исходного кода в инспекторе.
8. Быстрый поиск функции для отладки
1. Найдите строку в инспекторе и добавьте точку останова
2. Добавьте отладчик в свой скрипт
В обоих этих решениях вам придется вручную перемещаться по своим файлам, чтобы изолировать конкретную строку, которую вы хотите отладить. Что, вероятно, менее распространено, так это использование консоли. Используйте debug(funcName) в консоли, и скрипт остановится, когда достигнет функции, которую вы передали.
Это быстро, но недостатком является то, что он не работает с приватными или анонимными функциями. В противном случае это, вероятно, самый быстрый способ найти функцию для отладки. (Примечание: есть функция console.debug, которая не одно и то же, несмотря на схожее название.)
Введите debug(car.funcY) в консоли, и скрипт остановится в режиме отладки, когда получит вызов функции car.funcY:
9. Нерелевантные скрипты черного ящика
Сегодня в наших веб-приложениях часто используется несколько библиотек и фреймворков. Большинство из них хорошо протестированы и относительно свободны от ошибок. Но отладчик по-прежнему обращается ко всем файлам, которые не имеют отношения к этой задаче отладки. Решение состоит в том, чтобы поместить в черный ящик сценарий, который вам не нужно отлаживать. Это также может включать ваши собственные сценарии. Подробнее об отладке черного ящика читайте в этой статье.
10. Найдите важные вещи в сложной отладке
При более сложной отладке иногда требуется вывести много строк. Одна вещь, которую вы можете сделать, чтобы сохранить лучшую структуру ваших выходных данных, — это использовать больше консольных функций, например, console.log, console.debug, console.warn, console.info, console.error и т. д. Затем вы можете отфильтровать их в своем инспекторе. Иногда это не совсем то, что вам нужно, когда вам нужно отлаживать JavaScript. Вы можете проявить творческий подход и стиль ваших сообщений, если вы того пожелаете. Используйте CSS и создавайте свои собственные структурированные консольные сообщения, когда хотите отлаживать JavaScript:
В console.log() вы можете установить %s для строки, %i для целых чисел и %c для пользовательского стиля. Вы, вероятно, можете найти лучшие способы использования этих стилей. Если вы используете одностраничную структуру, вам может понадобиться один стиль для сообщений просмотра, а другой — для моделей, коллекций, контроллеров и т. д.
11. Наблюдайте за конкретными вызовами функций и аргументами
В консоли Chrome вы можете следить за определенными функциями. Каждый раз, когда функция вызывается, она будет регистрироваться со значениями, которые были переданы.
Это отличный способ увидеть, какие аргументы передаются в функцию. В идеале консоль могла бы сказать, сколько аргументов ожидать, но не может. В приведенном выше примере func1 ожидает три аргумента, но передает только два. Если это не обрабатывается в коде, это может привести к возможной ошибке.
12. Быстрый доступ к элементам в консоли
Более быстрый способ сделать querySelector в консоли — использовать знак доллара. $(‘css-selector’) вернет первое совпадение с селектором CSS. $$(‘css-selector’) вернет их все. Если вы используете элемент более одного раза, стоит сохранить его как переменную.
Теперь вы можете изменить все, что захотите. Измените заголовок, отредактируйте параметры и нажмите "Отправить повторно".
Ниже я представляю запрос дважды с разными свойствами:
14. Перерыв при смене узла
DOM может быть забавным. Иногда что-то меняется, и ты не знаешь почему. Однако, когда вам нужно отладить JavaScript, Chrome позволяет приостановить работу при изменении элемента DOM. Вы даже можете отслеживать его атрибуты. В Chrome Inspector щелкните элемент правой кнопкой мыши и выберите нужный параметр перерыва:
15. Воспользуйтесь сервисами ускорения страницы
Существует множество сервисов и инструментов, которые можно использовать для аудита JavaScript вашей страницы и выявления замедлений или проблем. Одним из таких инструментов является Raygun Real User Monitoring. Это может быть полезно по другим причинам, помимо выявления проблем с JavaScript — медленная загрузка внешних скриптов, ненужный CSS, слишком большие изображения. Это может помочь вам узнать о проблемах JavaScript, которые вызывают непреднамеренное увеличение времени загрузки или неправильное выполнение.
Вы также сможете измерять улучшения производительности JavaScript и отслеживать их с течением времени.
.jpg)
16. Точки останова везде
Наконец, проверенная и верная точка останова может оказаться успешной. Попробуйте использовать точки останова по-разному в разных ситуациях.
Вы можете щелкнуть элемент и установить точку останова, чтобы остановить выполнение при изменении определенного элемента. Вы также можете перейти на вкладку «Отладчик» или вкладку «Источники» (в зависимости от вашего браузера) в инструментах разработчика и установить точки останова XHR для любого конкретного источника, чтобы он останавливался на запросах Ajax. В том же месте вы также можете приостановить выполнение кода при возникновении исключений. Вы можете использовать эти различные виды точек останова в инструментах браузера, чтобы максимизировать свои шансы найти ошибку, не тратя время на сторонние наборы инструментов.
Заключение
Подводя итог, можно сказать, что существует множество способов отладки кода JavaScript. Мы перечислили шестнадцать из них здесь. Существует также полезная статья, в которой перечислены инструменты отладки JavaScript, если вы хотите приступить к расширению инструментов своего браузера с помощью сторонней помощи. В любом случае вы сможете использовать эти советы, чтобы приступить к отладке кода JavaScript и получить код без ошибок, готовый к развертыванию и отправке!
Хотите получить стопроцентную видимость ошибок JavaScript?
Raygun предоставляет диагностическую информацию, необходимую для быстрого обнаружения и диагностики ошибок JavaScript. Благодаря поддержке всех фреймворков JavaScript и реализации с помощью нескольких строк кода вы можете начать исправлять ошибки во время перерыва на кофе.
Попробуйте бесплатную пробную версию и начните отслеживать через несколько минут.
Читайте также: