Падение приложения, crash без визуализации

← →
Rouse_ © (2013-05-16 19:56) [80]

0EEDFADE - это код дельфийского исключения. т.е. штатный raise

cDelphiException = $0EEDFADE;

Теперь тебе нужно расрутить цепочку SEH фреймов в обратном порядке. Первый фрейм находится в FS:[0].

Скачай Jedy Library там в папке Debug кажется был пример кода, который выполняет данные действия. (потребуется MAP файл чтобы получить нечно читабельное).
Когда выствоишь цепочку - все сам увидишь...

← →
Es (2013-05-16 21:32) [81]

так... начинаются чудеса...

Я так понял, что все это результат искусственно вызванного исключения. Сделал такой код:

var i: integer; begin i := 0; ShowMessage(FloatToStr(5 / i)); end;

Запускаю... Обработчик VEH у меня так вот начинается:

function VectoredHandler(ExceptionInfo: PEXCEPTION_POINTERS): LongInt; stdcall; var Mes: string; begin result := EXCEPTION_CONTINUE_SEARCH; Mes := "hInstance: $"+IntToHex(HInstance, 8); ...

В переменной Mes я планирую собирать нужную строку для вывода в лог.
Так вот... После начала исключения попадаю в VectoredHandler. Присваивается Result, дальше отладчик переходит на строку:

> Mes := "hInstance: $"+IntToHex(HInstance, 8);

При ее выполнении... Попадаю опять в начало VectoredHandler, поток тот же! То есть, как я понимаю, в IntToHex возникло исключение! Если его убрать - проходит дальше нормально... Оч. интересно, почему IntToHex начал вызывать исключение...

При тестовом генерировании исключения raise EDivideByZero ничего такого не было...

← →
Плохиш © (2013-05-17 01:06) [82]

> Rouse_ © (16.05.13 19:46) [78]

А, понял, если лопнуло колесо, надо начать с переборки двигателя.

PS. Искать надо там, где потерял, а не в соседних кустах. И не надо усложнять простое.

← →
Германн © (2013-05-17 02:05) [83]

> Плохиш © (17.05.13 01:06) [82]
>
>
> > Rouse_ © (16.05.13 19:46) [78]
>
> А, понял, если лопнуло колесо, надо начать с переборки двигателя.
>
>

Не все исключения можно обработать стандарно-простым способом.
Блок
try ... except
не всегда сможет отловить исключение. Да и поскольку в проекте ТС используется Эврика и поскольку Эврика тоже ничего не ловит, то значит проблема гораздо глубже.
P.S.
Я лично сомневаюсь, что ТС сможет сам найти причину проблемы. Про SEH фреймы он знает только по наслышке (Про VEH я уже молчу. Я и сам только в этой ветке про него узнал :). Разворачивать стек не умеет. А нанять Розыча платно не потянет. :)

← →
Inovet © (2013-05-17 04:37) [84]

> [82] Плохиш © (17.05.13 01:06)
> Искать надо там, где потерял, а не в соседних кустах.

Могло закатиться в соседние.

← →
Rouse_ © (2013-05-17 10:26) [85]

Плохиш © (17.05.13 01:06) [82] А, понял, если лопнуло колесо, надо начать с переборки двигателя.
Это ты предлагаешь перебирать движок, пытаясь анализировать код наобум.
Ошибка в 17-ой строке, можно начать прямо с нее.

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

Знаю одного человека, он до сих пор, вместо того чтобы воспользоваться отладчиком, предпочитает по два три часа вычитывать код, пытаясь найти место ошибки. Очень высокопроизводительный и профессиональный подход, знаете-ли...

← →
Плохиш © (2013-05-17 10:40) [86]

> Rouse_ © (17.05.13 10:26) [85]
> Знаю одного человека, он до сих пор, вместо того чтобы воспользоваться
> отладчиком

Хм, воспользоваться отладчиком, я здесь тоже уже предлогал. Но что-то не видно здесь использования отладчика.

PS. У меня тоже есть пример любителя копи-паста. Одинаковый код копируется n-раз, после чего в нём находится ошибка, исправляется в m-раз. После чего периодически выскакивает ошибка в ситуациях n-m. Вывод гениальный "Визуальная студия компилирует один и тот же код по разному."

PPS. А тут, судя по условиям в [0] и адресе в исключении, проблемы с синхронизацией обращений к одним переменным из разных потоков. И я не удивлюсь, если автор считает, что это должен разруливать компилятор, виндовс или пушкин.

← →
Rouse_ © (2013-05-17 10:58) [87]

> Одинаковый код копируется n-раз, после чего в нём находится
> ошибка, исправляется в m-раз.

Хе :)

> PPS. А тут, судя по условиям в [0] и адресе в исключении,
> проблемы с синхронизацией обращений к одним переменным
> из разных потоков

Да, может быть и такой вариант, но к разрушению стека он привести не должен, если конечно данные переменные не используются в качестве указателей на буфер.

← →
Es (2013-05-17 11:00) [88]

Удалено модератором

← →
Es (2013-05-17 11:03) [89]

Rouse_, а ты не прокомментируешь [81] ? (

Не понимаю... Такое ощущение, что после возникновения исключения я попадаю в функцию обработки VEH в каком-то "не очень" правильном состоянии, что обычная IntToHex приводит, видимо, также к исключению.

← →
Rouse_ © (2013-05-17 11:08) [90]

> Es (17.05.13 11:00) [88]

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

> Es (17.05.13 11:03) [89]
> Rouse_, а ты не прокомментируешь [81] ? (

нужно код смотреть целиком, но это не раньше понедельника-вторника, сейчас завал...

← →
Inovet © (2013-05-17 11:11) [91]

> [86] Плохиш © (17.05.13 10:40)
> выскакивает ошибка в ситуациях n-m

Особенно интересен эффект, когда n<m. Тогда виноват уже сам Билл Гейтс.

← →
Es (2013-05-17 11:38) [92]

> Кстати он может быть не так уж и не прав

да кто же спорит! Но этот совет - утопия, если хотя бы как-то сузить место поиска хотя бы до одного модуля - еще что-то можно смотреть наобум. Но в таком виде "У тебя где-то ошибка" - что толку от этого. Я и сам понимаю, что где-то что-то не так написано. А учитывая что под нагрузкой от нескольких тысяч источников программа падает раз в неделю, а иногда в две (а вот иногда два раза в день)...Конечно, отладчик тут в помощь...

← →
Es (2013-05-17 13:35) [93]

Упростил исходники как только смог. Вот выложил:

http://yadi.sk/d/_pflEa3b4v2I5 (нужно нажать "Скачать", 17 Кбайт)

Вкратце:

1) ставим обработчик:

gExceptHandler := AddVectoredExceptionHandler(0, @VectoredHandler);

2) вот текст handler"а:

function VectoredHandler(ExceptionInfo: PEXCEPTION_POINTERS): LongInt; stdcall; var Mes: string; ss: TStringStream; begin result := EXCEPTION_CONTINUE_SEARCH; if RemoveVectoredExceptionHandler(gExceptHandler) > 0 then beep; Mes := "hInstance: $"; Mes := Mes + IntToHex(HInstance, 8)+#13#10; Mes := Mes +"ExceptionCode: $"+IntToHex(ExceptionInfo.ExceptionRecord.ExceptionCode, 8)+#13#10 +"ExceptionAddress: $"+IntToHex(Integer(ExceptionInfo.ExceptionRecord.ExceptionAddress), 8) ; ss := TStringStream.Create(Mes); PostMessage(Form1.Handle, WM_USER+1, 3345690, Integer(Pointer(ss))); end;

3) делаем такое исключение:

raise EDivByZero.Create("test");

все отлично перехватывается, логируется

4) делаем вот так:

var i: integer; begin i := 0; ShowMessage(FloatToStr(5 / i));

И тут все уже не очень. Выполняется строчка:

> result := EXCEPTION_CONTINUE_SEARCH;

Потом выполняется строчка:

>if RemoveVectoredExceptionHandler(gExceptHandler) > 0 then
> beep;

можно её убрать - толку нет, я просто экспериментировал - если убрать обработчик - пофигу.

Далее исполняется удачно:

> Mes := "hInstance: $";

А вот тут фейл:

> Mes := Mes + IntToHex(HInstance, 8)+#13#10;

После предыдущей строчки отладчик опять прыгает в начало на:

> result := EXCEPTION_CONTINUE_SEARCH;

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

← →
Rouse_ © (2013-05-17 22:36) [94]

> Es (17.05.13 13:35) [93]

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

← →
Rouse_ © (2013-05-17 22:49) [95]

Кстати получился достаточно интересный механизм переполнения. Раньше с именно такой ошибкой я не сталкивался, так что тебе спасибо за данный вариант кода.
Хорошее пополнение моей коллекции :)

← →
Es (2013-05-18 00:58) [96]

Rouse_, очень рад, что повеселил :)

Также рад, что в общем правильно догадался:

1) происходит исключение в IntToHex, поэтому опять попадаем в обработчик VectoredHandler
2) в VectoredHandler мы попадаем в очень как бы сказать "сыром" состоянии, что многие телодвижения также приводят к повторным исключениям.

Отсюда вопросы:

а) но ведь я компилил код и со строчкой:

... result := EXCEPTION_CONTINUE_SEARCH; if RemoveVectoredExceptionHandler(gExceptHandler) > 0 then beep; ...

При этом видно, что RemoveVectoredExceptionHandler отрабатывает! Почему же повторное исключение в IntToHex приводит опять к вызову VectoredHandler, по идее "хук" уже должен быть снят?

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

> Es (18.05.13 00:58) [96]
>
> Rouse_, очень рад, что повеселил :)

Ты не совсем правильно понял его смайлик. Про пополнение своей коллекции он сказал на полном серьёзе.

> и что же блин делать? Ведь в контексте решаемой задачи я
> понятия не имею какое исключение там у меня вызывается и
> вообще в чем проблема. Даже если я получу доступ в VectoredHandler,
> то мне я так понимаю нужно написать мега безопасный код,
> который с максимум вероятности сможет вывести в лог хоть
> что-то. Мои знания на этом точно закончились (

Что делать? "Трясти" как говорил Василий Иванович (с) в известном анекдоте. Не пытайся сразу написать "супер-мега-безопасный" универсальный код, который сразу поможет узнать "Кто виноват?" и "Что делать?". Если бы такой код можно было бы написать, авторы Эврики давно бы его написали.

← →
Es (2013-05-19 21:16) [98]

> Ты не совсем правильно понял его смайлик. Про пополнение
> своей коллекции он сказал на полном серьёзе.

это ты не совсем верно понял меня)

> При этом видно, что RemoveVectoredExceptionHandler отрабатывает!
> Почему же повторное исключение в IntToHex приводит опять
> к вызову VectoredHandler, по идее "хук" уже должен быть
> снят?

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

Можешь проверить с первым вариантом исключения, изменив код обработчика вот так:

function VectoredHandler(ExceptionInfo: PEXCEPTION_POINTERS): LongInt; stdcall; var Mes: string; ss: TStringStream; begin result := EXCEPTION_CONTINUE_SEARCH; if RemoveVectoredExceptionHandler(gExceptHandler) > 0 then beep; raise EDivByZero.Create("test");

← →
Es (2013-05-20 11:29) [100]

Rouse_, что делать то? ((

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

Что значит что делать? Логировать :)

var InVectoredHandler: Boolean = False; function VectoredHandler(ExceptionInfo: PEXCEPTION_POINTERS): LongInt; stdcall; var Mes: string; ss: TStringStream; begin if InVectoredHandler then Exit; InVectoredHandler := True; try result := EXCEPTION_CONTINUE_SEARCH; // выполняем подготовительные действия, по аналогу с _HandleOnException asm CLD FNINIT FWAIT FLDCW Default8087CW end; if RemoveVectoredExceptionHandler(gExceptHandler) > 0 then beep; Mes := "hInstance: $"; Mes := Mes + IntToHex(HInstance, 8)+#13#10; Mes := Mes +"ExceptionCode: $"+IntToHex(ExceptionInfo.ExceptionRecord.ExceptionCode, 8)+#13#10 +"ExceptionAddress: $"+IntToHex(Integer(ExceptionInfo.ExceptionRecord.ExceptionAddress), 8) ; ss := TStringStream.Create(Mes); PostMessage(Form1.Handle, WM_USER+1, 3345690, Integer(Pointer(ss))); finally InVectoredHandler := False; end; end;

← →
Es (2013-05-22 13:49) [102]

Еще раз упало:

Faulting application OfflineServer.exe, version 1.0.1.103, time stamp 0x2a425e19, faulting module ntdll.dll, version 6.0.6002.18541, time stamp 0x4ec3e3d5, exception code 0xc0000005, fault offset 0x00065cd4, process id 0x2bd8, application start time 0x01ce52d60ab69ee2.

Вот я думаю, если бы так все портилось - разве не были бы смещения отфонарные абсолютно? А тут так стабильно наблюдается или 0x00041440 или 0x00065cd4... неужели совпадение.

Падение приложения, crash без визуализации Найти похожие ветки