ехе закрывается сам по себе...

← →
Tom (2004-06-02 10:56) [0]

Всем привет. Хочу поделится очень странной проблеммой. Странной потому что ума не приложу почему это происходит.
В дебагере все работает ОК. А вот ехе при работе внезапно закрывается сам по себе. (Случается редко но метко :) ) (никаких условних close-ov в программе нет) Программа использует блокируюшиий сокет и потоки. Что может это вызывать?

← →
panov © (2004-06-02 10:57) [1]

Ошибка в программе.

← →
Gero © (2004-06-02 10:59) [2]

А может и не в программе.
А может это только сон...

← →
Smithson © (2004-06-02 11:00) [3]

Настройка ОС - не выводить сообшение об ошибке программы и завершать аварийную программу. Вот ее молча и закрывают.

← →
Smithson © (2004-06-02 11:00) [4]

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

← →
Tom (2004-06-02 11:03) [5]

Если у кого опыт с этим посоветуйте какого рода ошибку искать?

← →
Gero © (2004-06-02 11:05) [6]

> Если у кого опыт с этим посоветуйте какого рода ошибку искать?

Если программа компилируется, то точно не синтаксическую.

← →
YurikGL © (2004-06-02 11:05) [7]

>какого рода ошибку искать

Искать в 17-й строке

← →
Digitman © (2004-06-02 11:07) [8]

> Tom

если под дебагером все в порядке, то что-то, вероятно, связанное с нарушением межпоточной синхронизации

← →
Tom (2004-06-02 11:12) [9]

В дебагере за все время один раз был случай : выдало exception
с окошком F12(assembly) и при попытке отладки опять вылазило это окно->то есть невозможно было отследить где произошел exception.

← →
Tom (2004-06-02 11:17) [10]

Соообшение было : "Access Violation"

← →
Digitman © (2004-06-02 11:18) [11]

> В дебагере за все время один раз был случай : выдало exception

уже подозрительно

> с окошком F12(assembly) и при попытке отладки опять вылазило
> это окно->то есть невозможно было отследить где произошел
> exception.

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

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

← →
Тимохов © (2004-06-02 11:19) [12]

> Если у кого опыт с этим посоветуйте какого рода ошибку искать?

скажу честно и без издевки - такие ошибки можно искать (если они не нашлись за первые 2 часа) только правильным переписыванием всего... :(( Ну или хотя бы просмотром кода, возможно, с его переработкой.

← →
Tom (2004-06-02 11:23) [13]

Насколько понимаете в Ассемблере ни в зуб ногой (жаль но так). Потому вопрос: как по этому окошку понять в каком модуле проблемма?

← →
Tom (2004-06-02 11:24) [14]

>>Тимохов
O переписке и думать не хочется (4 месяца работы) потому попытаюсь искать.

← →
Digitman © (2004-06-02 11:25) [15]

> Tom (02.06.04 11:17) [10]
> Соообшение было : "Access Violation"

не могло быть оно таким !

а могло быть ТОЛЬКО таким : "Access Violation at ..."

вот это самое at ... и дает весьма предметную инф-цию для исследования причин

← →
Тимохов © (2004-06-02 11:27) [16]

> Tom (02.06.04 11:24) [14]

ищите.

если вы уж решили искать, то попробуйте все куски кода обрамить в try except для того, чтобы все ошибки кидать в лог. например, в текстовый файл (пишите в него текст ошибки, id потока). уже будет какая-то информация.

я бы с этого начал
имхо

← →
Tom (2004-06-02 11:31) [17]

>>Тимохов
В том то и дело что имеется даже ApplicationEvent который OnException пишет в лог но он ничего не дал!

>>Digitman
А как по этому адресу понять где ошибка?

← →
Тимохов © (2004-06-02 11:33) [18]

> Tom (02.06.04 11:31) [17]

applicationevent не дает исключений, которые возникли в потоках...
если у вас есть необработанное исключение в excute, то поток пректатится а ислкюченией сохранится в fatalexception. Вы должны его сами обработать в onterminate.

← →
Tom (2004-06-02 11:38) [19]

Ок,попробую обработать fatalexception посмотрим на результаты.
Дело еще в том что на три дня тестирования это один раз случилось так что придется ждать :)
Спасибо за помощ! Буду сообщать о развитии.

> А как по этому адресу понять где ошибка?

в ран-тайм в try..except-обработчике исключения можно выделить из строки сообщения этот адрес, преобразовать его к типу pointer, далее выполнить FindHInstance(адрес), и если результат ф-ции не равен nil выполнить GetModuleFileName(), получив имя файла PE-модуля .. тем самым ты сразу определишь, происходит ли искл-е в PE-модуле самого приложения либо оно происходит в одном из статически/динамически загружаемых PE-модулях библиотек

> Tom

настоятельно рекомендую во всех методах Execute() всех поточных классов сделать следующее :

procedure TMyThread.Execute;
begin
try
... здесь собственно алгоритм поточного метода
except
on E:Exception do
WriteLog(e.Classname + " " + e.Message + " " + ClassName + " " + InttoStr(ThreadId)); //запись в протокол инф-ции о любом потенциальном непредвиденном исключении
end;
end;

разумеется. ф-ция WriteLog д.б. потокобезопасной

Стек где-то иногда "грохаешь".

Пример:
type
Tb = array[0..4095] of byte;
Pb = ^Tb;

procedure SomeFunction;
var B : Pb;
begin
..........
GetMem(B, sizeof(Tb));
..........
..........
FillChar(B, sizeof(Tb), 0);
..........
end;

> Verg © (02.06.04 11:57) [22]

а запросто, кстати ..

абсолютно реальная ситуация, когда процесс снимается системой втихомолку

АВТОРУ.
Может интересно будет, сделал тут как говорит Digitman (самому интересно было).

type TTestObject = class a: integer; end; procedure TForm1.Button1Click(Sender: TObject); var kO: TTestObject; kHI: LongWord; kBuffer: packed array [0..1024] of char; begin kO := nil; try kO.a := 2; // генерация исключения except on kE:EAccessViolation do begin kHI := FindHInstance(kE.ExceptionRecord.ExceptionAddress); GetModuleFileName(kHI, kBuffer, SizeOf(kBuffer)); ShowMessage(kBuffer); // покажет имя модуля raise; end; end; end;

> Тимохов © (02.06.04 12:04) [24]

в случае, на который намекает Verg, эта инф-ция, даже если она будет получена, попросту бесполезна, ибо при "уродовании" содержимого стэка возврат из п/п может произойти как в любой непредcказуемый модуль, так и в "никуда"

Совет - включить в настройках компилятора ВСЕ проверки

← →
Григорьев Антон (2004-06-02 13:30) [27]

> Насколько понимаете в Ассемблере ни в зуб ногой (жаль но
> так). Потому вопрос: как по этому окошку понять в каком
> модуле проблемма?

Посмотреть окно стека. Там можно понять, из какой функции произошёл вызов ассемблерного кода.

Нечего смотреть если стек разрушен

ехе закрывается сам по себе... Найти похожие ветки