Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Тихо умирающее приложение [D7, WinXP]

Страницы: 1 2 3 >
AlexNe © (2008-07-05 18:41:00)
Уважаемые эксперты! Похоже я своими стараниями попал
в ситуацию из которой пока не вижу выхода.
Суть проблемы:
Имеется приложение, работающее с различными удаленными серверами через TSocketConnection, c базой данных Interbase, и с сервером реального времени, который крутится на DOS машине - соотв. через синхронный сокет TIdTCPClient.
Для работы с каждым сервером имеется отдельный поток,
причем поток сокета TIdTCPClient имеет наивысший приоритет.
Приложение работает под WinXP, работает без замечаний иногда 9 часов, иногда 3, затем элегантно, без каких либо сообщений схлопывается (а следом закрываются сервера).
Отслеживание возникающих исключений
(посылка сообщений из Application.OnException другой программе) не дало ничего - все чисто до самого схлопывания.
Запустить программу надолго под отладчиком Delphi я не имею возможности.
Безуспешные попытки найти причину доводят меня до отчаяния.
Уже вырубил на всех TSocketConnection свойство SupportCallBacks в False. Во всех Еxecute потоков защитил в
try-except все что только возможно - не помогает!

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

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

Loginov Dmitry (2008-07-11 21:27:00) [2]
> Вот, после Free нужно установить все разрушенные 'переменные'
> на адрес $80808080. А еще лучше воспользоваться FastMM,
> он в режиме FullDebugMode сам всё сделает.

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

Дмитрий Белькевич (2008-07-11 19:58:00) [3]
>Т.е. присвоение соотв. переменной $80808080 в OnTerminate или OnDestroy?

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

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

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

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

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

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

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

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

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

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

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

Anatoly Podgoretsky (2008-07-11 11:29:00) [4]
> Alex_Ne (11.07.2008 11:25:41) [41]

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

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

Alex_Ne (2008-07-11 11:29:00) [5]
to Дмитрий Белькевич ©

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

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

Alex_Ne (2008-07-11 11:25:00) [6]
to Дмитрий Белькевич ©
to Anatoly Podgoretsky ©

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

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

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

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

Сергей М. (2008-07-09 14:14:00) [7]

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

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

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

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

Anatoly Podgoretsky (2008-07-09 13:02:00) [8]
> Дмитрий Белькевич (09.07.2008 12:24:38) [38]

Для того что бы отличить не инициализированое, от уничтоженого.
Методика из FastMM

Дмитрий Белькевич (2008-07-09 12:24:00) [9]
>Легко говорить. А кто заплатит за такую переделку?
>Как говортся - хорошо быть здоровым и богатым.;)

Лишние писюки - продать, купить однокристалок. Разницу (если останется) - пропить ;)
Вообще, всё равно придётся им что-то менять, просто 'закопаются' со временем. Хотя, может быть я и не прав. Все обстоятельства мне неизвестны.

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

Почему, кстати? Нашел только, что FastMM в FullDebugMode атоматом забивает память разрушенных объектов и строк этим значением.

Вот, кстати, еще одна идея: поставить FastMM в FullDebugMode.

Anatoly Podgoretsky (2008-07-09 00:31:00) [10]
> Дмитрий Белькевич (08.07.2008 22:37:35) [35]

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

SergeyIT (2008-07-09 00:02:00) [11]

> Дмитрий Белькевич © (08.07.08 22:37) [35]
> разумно выбросить весь дос и вообще все лишние писюки

Легко говорить. А кто заплатит за такую переделку?
Как говортся - хорошо быть здоровым и богатым.;)

Дмитрий Белькевич (2008-07-08 22:37:00) [12]
>Т.е. какая-то аномалия при работе сокета DOS-Windows.

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

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

Сделать единый движок для 'пропихивания' инфы в компьютер. И несколько разных драйверов для разных входных данных.

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

AlexNe (2008-07-08 22:10:00) [13]
Случилось! Дебаггер указал на ошибку в потоке, в котором сидит IdTCPClient. Лог застопорился перед чтением свойства объекта-наследника соотв. потока. Т.е. какая-то аномалия при работе сокета DOS-Windows.
К сожалению проверить и уточнить получится нескоро, командировка кончилась. Поскольку моя работа с системой прерывается, тему считаю временно закрытой. Всем спасибо за потраченное время и ценную информацию.

Сергей М. (2008-07-08 19:26:00) [14]

> AlexNe (08.07.08 19:18) [31]

Смотря что ты подразумеваешь под "сетевой частью".

Подозреваю, что ты не имеешь ни малейшего представления о модели OSI.

AlexNe (2008-07-08 19:22:00) [15]
to Eraser ©
Предположение появилось из-за чрезвычайной редкости события - 1-2 раза за сутки, при том что старая версия с теми же серверам, оборудованием и в том же режиме не падает (хотя и теряет иногда важную информацию)

AlexNe (2008-07-08 19:18:00) [16]
>Сетевая часть думаю особо не при чем.

Сергей М. (2008-07-08 17:25:00) [17]

> синхронный TIdTCPClient для работы с сервером под DOS

Клиенту глубоко фиолетово, под какой ОС работает сервер.
Равно как и наоборот.
И синхронность или асинхронность тут совершенно ни причем.

AlexNe (2008-07-08 16:36:00) [18]
Извиняюсь за задержку - у меня последний день командировки и рвут на части.
to Slym ©
Возможно, что-то было с TClientSocket в потоке сделано не так, нужно рыть старый исходник. Но сокет с DOS машиной через несколько минут 10Гц обмена вис, причем ситуация решалась только перезагрузкой DOS

to Дмитрий Белькевич ©
Нет, не усложнено. Система решает задачу управления научным оборудованием, которое разбросано в радиусе 50 м и имеет ограничения по длине проводов связи - отсюда наличие множества серверов на разлинух компах.

to Slym ©
>2. что за DOS сервер, не порали найти/сделать win аналог?
Найти нельзя. Сделать - во- первых нужна система жесткого реального времени, тут скорее QNX. Но главное, то кол-во самодельных железок, для которых по мере развития системы писались дрова - все переписть в обночасье никак не получится, а останавливать ради этого систему никто не даст. Так что живем как живем.

to Eraser ©
? - если кто-то приостановит обмен с DOS машиной на 0.5 с., сработает защита, которая останавливает плавное движение конструкции весом 3.5т.
> Если приложение падает и даже исключение не вылетает, то скорее всего > где-то неверная работа с памятью
что-то похожее на конфликт реентерабельности наблюдается по логам, - два раза произошел вылет при входе в Timer.OnTimer (там ничего нет, кроме обновления интерфейсных элементов).
Поставил на тестирование - до вечера, последний шанс отловить барабашку.

Eraser (2008-07-08 15:02:00) [19]
> [0] AlexNe (05.07.08 18:41)

> причем поток сокета TIdTCPClient имеет наивысший приоритет.

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

Slym (2008-07-08 12:27:00) [20]
Дмитрий Белькевич © (08.07.08 12:25) [26]
Какую проблему решает система?
2. что за DOS сервер, не порали найти/сделать win аналог?

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »