Легко. Берем словарик, гугл, сап ноты, дохлый SDN/SCN, ведро кофе, отладчик, книжку по ABAP и отключаем соцсети. Дальше дело пяти минут разложить партейку в дамп и вывести отладчик на чистую воду. Зачем все это? Бывает, что приспичило найти ошибку, а разработчика нет под рукой.
У нас есть две ситуации. Когда все пропало и когда еще теплится. Они отличаются только временем вскрытия пациента, поэтому, соответственно, могут предоставить немного больше информации при свеженьком теле. Свеженький дамп обычно возникает, когда вы что-то делали, а он, бац, и нарисовался. Как синий экран смерти в винде, если кто помнит еще такие. Или как зависание MS DOS с абракадаброй на видюхе. Так вот, если дамп случился прямо при очевидцах, то там есть кнопочка посмотреть что же сейчас творится в памяти, выйдя в отладчик. Если вы поймали дамп, но закрыли с ним окно, то он протух. Его можно посмотреть в транзакции ST22, но уже без текущего состояния памяти в отладчике.
В первом случае ошибку найти можно чуть быстрее, во втором либо сложнее, либо можно повторить действия и надеяться на свеженький дампик.
Открыли дамп. Это такой красненький экран, который выглядит примерно так.
Много букв и все на вражеском. Дампы проще всего различать на системные и клиентские. В первом случае это ошибка системы, которую допустил вендор. Во втором, это косяки программистов заказчика или консультанта. Вторые дампы проще найти, повторить, уговорить разрабов исправить.
Ниже я расскажу как читать дампы, куда с ними бежать тем, кто еще не программист. Программисты тут ничего нового не найдут.
Первое и самое очевидное, это посмотреть что же написано на первом экране. Прямо перед вами. Зачастую там написана суть ошибки и место ее возникновения. Многие консультанты закрывают это окошко даже не прочитав, а зря, там в 90% случаев будет написано решение. Обычно дампы бывают системные с точки зрения базиса, когда не хватает памяти в системе, места в базе данных, полномочий для выполнения какой-то системной штуки, невозможности соединиться с системой. В таких случаях все будет написано откровенным английский текстом.
Второй случай, когда ломается какая-то «наша» разработка. И надо понять в каком месте мы что-то не учли, после чего система «упала». Для этого спускаемся чуть ниже.
Нас интересуют два раздела: Information on where terminated и Source Code Extract. Зачастую, глядя на них, можно понять суть ошибки.
Например, здесь система показывает, что сломалось что-то на строчке 7. Если перевести с английского кусочек кода чуть выше if P_NAME is initial, то можно догадаться, что в переменной P_NAME оказалось пусто, поэтому система не может дальше выполнять эту программу. Если причина, почему переменная пустая, не ясна, то открываем этот исходный код, кликнув на строчку 7 мышкой, ставим точку остановки и перезапускаем программу. В отладчике начинаем думать как она заполняется и почему там оказалось пусто. Скорее всего в настройках забыли указать значение в каком-то поле. Используя метод поиска «где это используется» можно найти то место, где переменная заполняется каким-либо значением. Дальше дело логики.
Если спуститься в дампе чуть ниже до раздела Chosen Variables, то там будут показаны значения переменных в момент возникновения ошибки. Можно посмотреть на них и увидеть, что мы в переменную не то записали, например. Так часто бывает, когда программист ожидает в коде получить число, а мы ему строчку на экране вводим. Или формат даты другой используем, или еще сто-пятнадцать причин.
В разделе Active Calls/Events мы видим, какие программы и подпрограммы были выполнены системой, что привело к возникновению ошибки. Если этот дамп случился в фоновом режиме, то можно проследить откуда «ноги растут».
Реже всего встречаются дампы с системными ошибками, связанными с внутренней кухней системы. Например, установили новый пакет обновлений, где что-то не учли, либо новая функциональность приехала. Поэтому рекомендуется ставить пакеты обновлений не самой первой свежести, а хотя бы с месячным отставанием.
Если у нас совершенно непонятная ситуация, то первым делом идем в раздел How to correct the error. Если там нет инструкции как исправить ситуацию (например, поменять параметр профиля системы), то там будут написаны ключевые слова, по которым можно поискать решения на SAP Support Portal в разделе Notes. Берем эти слова и начинаем искать по ни там. Опять же, в большинстве случаев уже будет выпущена нота с датой позже вашего самого свежего пакета обновления, где эта ошибка исправлена.
Если все совсем ах, то остается два варианта решения проблемы:
а) привлечь программиста, чтобы доскольнально выяснить что является причиной проблемы, а потом придумать к ней обходное решение (Workaround);
б) выставить в SAP Support Portal сообщение с ошибкой, приложить весь текст дампа в текстовом виде, а не скриншотиками.
One Comment
Calm
Стек вызовов полезно смотреть не только для фоновых дампов. Часто проблема находится не в том вызове, где программа упала, а выше, там где приготовились некорректные данные.
Еще иногда в дампе можно углядеть значения ключевых переменных. Например, на PNPCE программах полезно искать слово «PERNR», иногда там можно найти табельный номер, который завалил прогу в дамп. Но не всегда.