class RSUIEXCEPTIONHANDLERAPI_API se_translator_registry {
public:
se_translator_registry()
{
m_active = 0;
}
~se_translator_registry()
{
}
bool register_translator()
{
return (InterlockedCompareExchange(&m_active, 1, 0) == 0);
}
void unregister_translator()
{
InterlockedExchange(&m_active, 0);
}
private:
volatile long m_active;
se_translator_registry(const se_translator_registry&);
se_translator_registry& operator=(const se_translator_registry&);
};
Как быстрее найти иголку в стоге сена
Имется громадный проект, написанный на C++. Куча функций, процессов и т. п. Недавно выяснилось, что новые версии проекта почему-то нормально запускаются на одних компьютерах и ломаются на некоторых других. Есть подозрение, что это из-за перхода на UNICODE. Проверили процессы и функции, которые должны работать при запуске программы - вроде всё срабатывает нормально. Но всё равно программа где-то ломается. Сложность в том, что никак не получается определить, на какой именно функции ломается программа.
Есть ли более менее оптимальный способ определить, в каком именно месте сломалась программа на другом компьютере, не устанавливая Visual Studio на этом компьютере?
Есть ли более менее оптимальный способ определить, в каком именно месте сломалась программа на другом компьютере, не устанавливая Visual Studio на этом компьютере?
Во-первых, что значит ломается? И вообще, какой код содержит приложение: управляемый, или неуправляемый? Или и то, и другое?
Во-вторых, программы, обычно, вылетают вследствие возникновения необрабатываемого исключения. Для определения участка кода, выполняемого в данный момент программой, в управляемом коде используют обычно Environment::StackTrace, в неуправляемом коде - отладочные макросы, составленные на основе встроенных лексемм __FILE__ и __LINE__, а для контроля правильности работы программы в критических местах - макросы типа TRACE и ASSERT.
Самый же радикальный и верочный вариант - сохранять дамп упавшего приложения для дальнейшего его анализа под отладчиком.
Во-вторых, программы, обычно, вылетают вследствие возникновения необрабатываемого исключения. Для определения участка кода, выполняемого в данный момент программой, в управляемом коде используют обычно Environment::StackTrace, в неуправляемом коде - отладочные макросы, составленные на основе встроенных лексемм __FILE__ и __LINE__, а для контроля правильности работы программы в критических местах - макросы типа TRACE и ASSERT.
Самый же радикальный и верочный вариант - сохранять дамп упавшего приложения для дальнейшего его анализа под отладчиком.
У нас предусмотрены макросы для обработки исключений. И в данном случае выскакивет диалог, который должен появляться при обработке исключения. Дамп тоже получется сохранить. Но вот получить из этого дампа необходимую информацию- не удаётся. Если приложение запускается не на том компьютере, на котором компилировалось, Call Stack всегда получается пустой. Может, мы что-то не так делаем?
Тем не менее, туманная постановка вопроса. Получается что-то вроде "Имеется автомобиль за 40000$. Недавно выяснилось, что на ухабистых дорогах он глохнет и не едет. Есть подозрение, что это из-за перехода на green oil. Проверили клапана и свечи зажигания - всё ок. Есть две отвёртки и ключ на 24, но с их помощью проверить уровень масла не удаётся. Может, мы что-то неправильно делаем?"
Расскажите поподробнее, что за исключение, и при каких обстоятельствах оно возникает? Как сохраняете дамп (DrWatson, ADPlus, стандартные средства операционной системы)? Чем открываете дамп? Какую информацию несут отладочные диалоги? Может быть, имеет смысл включить отладочные проверки на выход за границы массива, переполнение и контроль целостности стека? Может быть, имеется возможность отлаживать решение удалённо (скажем, с помощью remote tool для MS Debugging Tools for Windows)?
Какова природа исключения? Это исключение .NET, C++ или исключение операционной системы (SEH и т. п.)?
Вопрос по поводу природы исполняемого кода (управляемый, неуправляемый?) также не раскрыт.
Наискорейший способ найти багу, в вашем случае - как можно точнее и лаконичнее описать проблему.
Расскажите поподробнее, что за исключение, и при каких обстоятельствах оно возникает? Как сохраняете дамп (DrWatson, ADPlus, стандартные средства операционной системы)? Чем открываете дамп? Какую информацию несут отладочные диалоги? Может быть, имеет смысл включить отладочные проверки на выход за границы массива, переполнение и контроль целостности стека? Может быть, имеется возможность отлаживать решение удалённо (скажем, с помощью remote tool для MS Debugging Tools for Windows)?
Какова природа исключения? Это исключение .NET, C++ или исключение операционной системы (SEH и т. п.)?
Вопрос по поводу природы исполняемого кода (управляемый, неуправляемый?) также не раскрыт.
Наискорейший способ найти багу, в вашем случае - как можно точнее и лаконичнее описать проблему.
Наш проект является надстройкой Autocad. Т. е., чтобы запустить проект надо сперва запустить Autocad, а потом Autocad закружает наш проект как приложение. Я не знаю, как правильно запускать Дамп для таких приложений. Подсоединение дампа к Solution нормальных результатов не даёт. (Ассемблерный код, из которого ничего не выяснишь)
Что вы имеете в виду насчёт природы исполняемого кода? Мне не знакомы понятия управляемого \ неуправляемого кода. К тому же не понимаю, как определить природу исключения. Буду благодарна, если поделитесь информацией по этим вопросам.
Что вы имеете в виду насчёт природы исполняемого кода? Мне не знакомы понятия управляемого \ неуправляемого кода. К тому же не понимаю, как определить природу исключения. Буду благодарна, если поделитесь информацией по этим вопросам.
Я уже рекомендовал для прочтения книгу.. В ней есть прекрасное описание создания дампов и пр. методов отладки приложений (как native так и dotNET)
Цитата: Ap0k
Я уже рекомендовал для прочтения книгу.. В ней есть прекрасное описание создания дампов и пр. методов отладки приложений (как native так и dotNET)
Да я видела отзывы об этой книге. Наверное, действительно стоило бы почитать. Единственная проблема: где её можно достать?
Цитата: Nadezda
Да я видела отзывы об этой книге. Наверное, действительно стоило бы почитать. Единственная проблема: где её можно достать?
http://files.zipsites.ru/books/programming/robbins_dzhon__otladka_prilozhenii_dlya_microsoft_net_i_microsoft_windows.rar
Весит собака правда 40 Mb.
Большое спасибо всем кто отозвался. Ошибку(деффект) выловить всё же получилось. Правда теперь возник дополнительный вопрос: может кто нибудь знает, зачем нужна функция InterlockedCompareExchange ?
А так же
Почему на некоторых компьютерах в какой-то момент функция register_translator() может вернуть значение true ?
А так же
Код:
Почему на некоторых компьютерах в какой-то момент функция register_translator() может вернуть значение true ?
Цитата: Nadezda
может кто нибудь знает, зачем нужна функция InterlockedCompareExchange ?
Код:
LONG InterlockedCompareExchange(
LONG volatile* Destination,
LONG Exchange,
LONG Comperand
);
LONG volatile* Destination,
LONG Exchange,
LONG Comperand
);
Функция выполняет атомарное сравнение двух чисел: того, которое лежит в Destination и второго Comperand. Если они оказываются равны, то значение в Destination замещается Exchange значением.
Функция в любом случае возрвращет предыдущее значение Destination.
Цитата: Nadezda
Почему на некоторых компьютерах в какой-то момент функция register_translator() может вернуть значение true ?
Потому что m_active по какой-то причине содержит 0. После этого вызова m_active принимает значение 1 (судя по коду).
В студии есть такая прекранейшая вещь и называеца она Remote Debugger... попробуй мож поможет... чтоб его запустить, надо чтоб на сервере (тобиш там где прога ломаеца) был запущен собсно RemoteDebuger, находиц он в папке:
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\<Платформа>\
устанавливаеца тупо копипастом...
а потом из VS на клиенте, просто атачимся (Debug->Attach to Process...) к процессу на удаленном сервере и всё... пробуем дебажить... =)))
P.S. софт дожен быть откомпилен в Debug режиме... так на всяк случай ;-)
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\<Платформа>\
устанавливаеца тупо копипастом...
а потом из VS на клиенте, просто атачимся (Debug->Attach to Process...) к процессу на удаленном сервере и всё... пробуем дебажить... =)))
P.S. софт дожен быть откомпилен в Debug режиме... так на всяк случай ;-)