> аномалия при работе сокета DOS-Windows


Что это за сокет такой "DOS-Windows" ?

Какое тебе вообще дело до сокета на другом конце соединения ?

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

to Дмитрий Белькевич ©  
to Anatoly Podgoretsky ©


> Наиболее вероятная аномалия - доступ к обломкам разрушенного
> объекта. Объектам после разрушения присваивай nil, может
> ошибку удастся 'проявить'. По AV доступа к 00000000.



> Не надо nil, лучше $80808080


Т.е. присвоение соотв. переменной $80808080 в OnTerminate или OnDestroy?
(штатно все объекты всюду убиваются или методом Free или с последующей установкой в Nil соотв. переменной)
Судя по последнему событию, которое удалось засечь перед отъездом -
похоже рушится незаметно поток, в котором сидит IdTCPClient.  При этом событие потока OnTerminate не возникает, т.к. не приходит соотв. лог. Далее, обращение в основном потоке (в обработчике TTimer.OnTimer) к его св-ву обрушивает приложение. По какой причине все это происходит без AV - для меня загадка. Связь через IdTCPClient также тестировалась и на помехи и на приход "неправильного" пакета и на разрыв сети - все обрабатывается корректно. И вообще, первый раз наблюдаю такое неуловимое чудо за 9 лет работы с Delphi.

Попробую промоделировать ситуацию дома. Если удастся найти разгадку - сообщу на форум. Спасибо еще раз за информацию.

to Дмитрий Белькевич ©  

> Если нужен хороший реалтайм, разумно выбросить весь дос
> и вообще все лишние писюки и, по возможности, самодельные
> железки вместе с дровами. Сделать промежуточный приём на
> однокристалках, постараться все данные собирать только ими,
>  благо сейчас их разных есть, можно и абсолютный аналог,
>  и дифференциальный, и цифру забирать, и по многим каналам
> сразу. Объединить их в сеть (есть железки с готовым железячным
> tcp стёком), и сливать информацию по мере доступности на
> писюк.


Прямо бальзам! Вы как будто мысли читаете - на самом деле выкинуть
нафиг DOS машину, или ограничить ее использование только как станции точного времени (10МГц таймер на основе PCI1780 и с привязкой времени по GPS приемнику)  - давняя мечта. Последние года два все новое именно и строится под децентрализованную архитектуру на отдельных программируемых платах - связь через tcp/ip или rs232. ИМХО более гибкий и технологичный с точки зрения развития/ремонта/обслуживания подход.  
Но избавиться от прошлого не так просто - о чем уже написано выше.

> Alex_Ne  (11.07.2008 11:25:41)  [41]

Три значения для переменной объекта позволяют сократить зону поиска.

nil - обращение не к инициализированому объекту
80808080 - обращение к разрушеному объекту
xxxxx - разрушение не контролируется тобой или забыл установить 80808080

>Т.е. присвоение соотв. переменной $80808080 в OnTerminate или OnDestroy?

Нет, после .free.

>штатно все объекты всюду убиваются или методом Free или с последующей установкой в Nil соотв. переменной

Вот, после Free нужно установить все разрушенные 'переменные' на адрес $80808080. А еще лучше воспользоваться FastMM, он в режиме FullDebugMode сам всё сделает. Да и вообще его стоит оставить вместо стандартного, реально быстрее работает, и в тяжелых случаях работы с памятью гораздо меньше её фрагментирует.

>При этом событие потока OnTerminate не возникает,

Странно, вообще-то. У нас в одном софте поток частенько раньше падал, пока не исправили всё. OnTerminate возникал всегда, 100%. Знаю, так как мы в нём порушенный поток пересоздаём, ну и в лог пишем, что упал.
Никогда не видел, что бы поток упал так, что даже OnTerminate не смог вызвать. Хотя, допускаю, что такое возможно.

>И вообще, первый раз наблюдаю такое неуловимое чудо за 9 лет работы с Delphi.

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

Плохо - это когда ты сам - в Беларуси, а софт - в Канаде, через 7 часовых поясов. Remoute debug помогает. Медленно, правда, но в особенно тяжелых случаях - единственное решение.

А случаи с потоками иногда бывают чудесные, да. Правда, в 100% оказывается, что сам где-то накосячил.

>Вы как будто мысли читаете

Угу, я хотел в конце дописать, что воспользовался телепатором ;) Впрочем, всё и так достаточно очевидно.

> Вот, после Free нужно установить все разрушенные 'переменные'
> на адрес $80808080. А еще лучше воспользоваться FastMM,
> он в режиме FullDebugMode сам всё сделает.


Одно другому не мешает.

Мне тоже кажется, что нужно выводить всё и смотреть каждую переменную в изменениях.
Я как-то написал программу, она работала, в ней были большие рассчёты. Но вот иногда с ошибочными результатами, хотя она не закрывалась. Лучше бы закрывалась. Ошибку я не видел в упор. Грешил на битую память компа и т. д.  Керк по аське меня убеждал: "Ищи глюк, он есть, но прячется".
И нашёл таки, хотя глюк был не мой, а паскальСкрипта. При присвоении переменной Integer суммы двух переменных Byte, он гнустно сначала считал результат байтом, а потом уж присваивал целому числу.
Не знаю другого гарантированного метода изобличения глюков, кроме логирования. ИМХО его и быть не может.