Отладка "оффлайн"

[konfet]

Ситуация такая. Время от времени у пользователей возникает некая ошибка (полю автоматически присваивается то значение, которое не должно присваиваться).
Нужно "размотать" ситуацию и понять, что именно в бизнес процессе и/или настройках и/или коде неправильно.
Я локализовал то место в коде, которое в конечном счете инициирует ошибку, и куда выполнение при данном наборе условий по идее не должно "проваливаться".
НО: код очень сложный, многоуровневый, этот набор условий - большой, воссоздать ситуацию и вычленить именно то условие или событие, которое привело к ошибке - трудно да и нет времени.
Хочу иметь на руках полную "картину преступления" в тот момент, когда в данное ошибочное место пользователь "провалится" в следующий раз.
Собственно вопрос: есть ли в аксапте некий метод (назовем его getSnapshot()), вызов которого запишет в некий журнал - таблицу БД или в файл следующую информацию:

1. Стек вызова;
2. Значения всех локальных и объектных переменных того места, откуда метод был вызван, а также всех локальных и объектных переменных всех уровней выполнения выше по стеку (кроме BLOB);
3. Возможно, выдаст и некое уведомление о факте проваливания, например на емейл.

Подозреваю, что похожая задача в аксапте решалась многими, и не хочу изобретать лисапед.

AX 4.0 sp3.

[Player1]

Оплата поставщику
Создание снимков изменений в базе данных

[konfet]

Спасибо. Но не совсем это то... там нету

Цитата:

Значения всех локальных и объектных переменных того места, откуда метод был вызван, а также всех локальных и объектных переменных всех уровней выполнения выше по стеку (кроме BLOB);

Хотя, на безрыбье...

[gl00mie]

Цитата:

Сообщение от konfet

Я локализовал то место в коде, которое в конечном счете инициирует ошибку, и куда выполнение при данном наборе условий по идее не должно "проваливаться".НО: код очень сложный, многоуровневый, этот набор условий - большой, воссоздать ситуацию и вычленить именно то условие или событие, которое привело к ошибке - трудно да и нет времени.

Прелестно!.. Если это - стандартный код (типа сопоставления или сводного), то вам можно только посочувствовать, если же код самописный... ну вы поняли Как писал Джон Роббинс в своей широко известной в узких кругах книге, лучший способ отладки - это вообще не доводить дело до отладки. Можно использовать, к примеру, контрактный подход и проверять пред-/пост-условия (см. также вспомогательные классы для этого). Это обычно позволяет быстро выявлять проблемы и не допускать распространения кривых данных по системе. "Минус" такого подхода в том, что его преимущества не даются бесплатно - требуются определенные трудозатраты на этапе написания кода, а если код уже написан, то придется его доработать напильником. Если сложность кода в том, что есть куча итераций обработки данных, в ходе которых состояния объектов и/или данные в таблицах меняются нетривиальным образом, то тут можно приделать некий код трассировки, который бы выводил куда-либо текущую информацию о наиболее важных объектах/таблицах (тем более если используются временные таблицы). Затем можно проанализировать трассировку и попытаться понять, что пошло не так.

Цитата:

Сообщение от konfet

Хочу иметь на руках полную "картину преступления" в тот момент, когда в данное ошибочное место пользователь "провалится" в следующий раз.

По-моему, в Аксапте штатно нет средств, позволяющих получить "снимок" всего состояния сессии, включая локальные переменные значимых и ссылочных типов каждого фрейма стека выполнения. В 4-ке работает Trace Parcer, но в вашем сценарии, я так понимаю, он не подходит (кажется, 4-ка еще не умеет циклически перезаписывать файл трассировки, ограничив его определенным размером). В общем, без доработки кода напильником с целью получения некой "телеметрии" тут, мне кажется, не обойтись.

[konfet]

Цитата:

Сообщение от gl00mie

Прелестно!.. Если это - стандартный код (типа сопоставления или сводного), то вам можно только посочувствовать, если же код самописный... ну вы поняли

Код, увы, полностью самописный и как вы наверное догадываетесь, никакого описания или рулезов к нему нет так что отладчик в данной ситуации похоже единственный помощник.

Цитата:

Сообщение от gl00mie

Как писал Джон Роббинс в своей широко известной в узких кругах книге, лучший способ отладки - это вообще не доводить дело до отладки. Можно использовать, к примеру, контрактный подход и проверять пред-/пост-условия (см. также вспомогательные классы для этого). Это обычно позволяет быстро выявлять проблемы и не допускать распространения кривых данных по системе.

Это советы из серии "лучше быть здоровым и богатым чем бедным и больным", которые, к сожалению, имеют мало успеха в России - у нас как правило сначала делают, а потом думают
В приложении толпой его авторов (стажеров одной из ведущих конс. фирм) просто навалена куча г-на, и никаких "классов проверок" в помине нет.
Ладно. Попробую допилить инструмент, предложеннный Ace of database, если что получится - отпишусь сюда.

[raz]

Статус "Отменено" в строках заказа

[belugin]

По идее, если сделать crashdump в этот момент, то можно в нем все есть. Осталось только проанализировать.

Я сам не пробовал. Еще вариант дождаться первого появления - сбросить стек в файлик в потом прологгировать весь код вверх по колстеку.

Еще вариант, при появлении вывести сообщение "срочно позовите техподдержку" и сделать там инструкцию breakpoint (правда, не уверен, что включение отладки для всех не является понижением быстродействия и дырой в безопасности).

[konfet]

А есть ли в аксапте методы типа, наверное, toString() которые выведут в xml или куда нибудь еще содержимое закладок Locals, Globals, This дебаггера?

[gl00mie]

Цитата:

Сообщение от konfet

Код, увы, полностью самописный и как вы наверное догадываетесь, никакого описания или рулезов к нему нет В приложении толпой его авторов (стажеров одной из ведущих конс. фирм) просто навалена куча г-на, и никаких "классов проверок" в помине нет.

Очень похоже на классическую ситуацию накопления технического долга, который в данном случае приходится теперь выплачивать вам. Мне кажется, присвоением одному полю "не того" значения тут дело не обойдется.

Цитата:

Сообщение от konfet

А есть ли в аксапте методы типа, наверное, toString() которые выведут в xml или куда нибудь еще содержимое закладок Locals, Globals, This дебаггера?

В том-то и дело, что нет, штатно только отладчик умеет это все разбирать и наглядно показывать.

[twilight]

Сделайте проверку значения и если оно не то, тогда генерируйте Error exception (транзакции там должны быть корректными, чтобы ничего из-за этого не рассинхронизировалось). Пользователи к вам обратятся по этой ошибке и можно будет зайти в отладчик и проанализировать.

[konfet]

Цитата:

Сделайте проверку значения и если оно не то, тогда генерируйте Error exception (транзакции там должны быть корректными, чтобы ничего из-за этого не рассинхронизировалось). Пользователи к вам обратятся по этой ошибке и можно будет зайти в отладчик и проанализировать.

Да, это самое простое, и я об этом думал, но... если меня не будет на рабочем месте, то бизнес-процесс встанет, и я буду "крайним"

[belugin]

Цитата:

Сообщение от konfet

Да, это самое простое, и я об этом думал, но... если меня не будет на рабочем месте, то бизнес-процесс встанет, и я буду "крайним"

if (Box::YesNo("Вы можете позвать пользователя konfet?"))
{
     breakpoint;
}

[konfet]

Спасибо всем участникам темы.
Остановился на модифицированном варианте Belugin: показал ребятам из поддержки, как (ручками) вытаскивать данные с дебагера, и вставил в проблемное место примерно такой код:

    res = UserInfoHelp::userInUserGroup(curUserId(), "Admin") && UserInfoHelp::userInUserGroup(curUserId(), "Support");
    if (!res)
    {
        throw info("Нештатная ситуация номер 001. Для завершения операции обратитесь в поддержку!");
    }
    else
    {
        breakpoint;
    }

[Romb]

Добрый день. Может у вас ситуация и не в этом, но обратите внимание на класс xSysLastValue и его метод getlast().

[Ivanhoe]

Не забудьте потом отключить debug на рабочей базе!

[lev]

Цитата:

Сообщение от konfet

Ситуация такая. Время от времени у пользователей возникает некая ошибка (полю автоматически присваивается то значение, которое не должно присваиваться).
Нужно "размотать" ситуацию и понять, что именно в бизнес процессе и/или настройках и/или коде неправильно.
Я локализовал то место в коде, которое в конечном счете инициирует ошибку, и куда выполнение при данном наборе условий по идее не должно "проваливаться".
НО: код очень сложный, многоуровневый, этот набор условий - большой, воссоздать ситуацию и вычленить именно то условие или событие, которое привело к ошибке - трудно да и нет времени.
Хочу иметь на руках полную "картину преступления" в тот момент, когда в данное ошибочное место пользователь "провалится" в следующий раз.
Собственно вопрос: есть ли в аксапте некий метод (назовем его getSnapshot()), вызов которого запишет в некий журнал - таблицу БД или в файл следующую информацию:

1. Стек вызова;
2. Значения всех локальных и объектных переменных того места, откуда метод был вызван, а также всех локальных и объектных переменных всех уровней выполнения выше по стеку (кроме BLOB);
3. Возможно, выдаст и некое уведомление о факте проваливания, например на емейл.

Подозреваю, что похожая задача в аксапте решалась многими, и не хочу изобретать лисапед.

AX 4.0 sp3.

Мне кажется где то уже писалось на форуме, но что то не могу найти.
Я для поиска "откуда это ... взялось" использую следующее:
1. Добавялете поле "CallStack" в журнал БД (SysDataBaseLog) (можно сделать отдельную связную табличку, что бы не корячить SysDataBaseLog).
2. Доработать метод insert() на таблице SysDataBaseLog, что бы в добавленное поле писался стэк вызова (xSession::xppCallStack()).
3. На проблемную таблицу включить Журнал БД.
4. Когда начнут жаловатся, открываем журнал БД и смотрим стэк вызова.

Первые два пункта мне кажется на форуме где то есть, можете поискать.

Конечно заполнение данного поля приведет к распуханию БД. Поэтому лучше сделать параметр, который бы включал и выключал запись стэка вызова в БД. И включать этот параметр только при необходимости (при ловле "блох" )

P.S. мне это ОЧЕНЬ помогает в жизни, т.к. приходится работать с кодом очень низкого качества. Только так смогли выудить кучу различных багов, которые делают полный бред, но в глаза не брасаются

[Logger]

Да, модифа со стеком вызова очень удобная.
Помогает понять в спорных ситуациях - это система сглючила или пользователь накосячил сам, а потом дурака включил.