Работа с потоками в Delphi

← →
Unknown user © (2009-01-24 22:10) [0]

Мне одному так кажется или все с этим сталкиваются? Отлаживать потоки в Delphi очень непросто. Пошаговая отладка невозможна из-за того, что отладчик непредсказуемо переключается с потока на поток. При пошаговой отладке рано или поздно происходит зависание среды.

← →
Юрий Зотов © (2009-01-24 22:12) [1]

Скорее первое.

← →
Unknown user © (2009-01-24 22:21) [2]

>Юрий Зотов

Тогда поделитесь опытом. Вы никогда не стыкались с таким поведением отладчика? (Я работаю в D5 но похожее наблюдал и в D2009, на разных компьютерах). Даже в демо приложении от Борланда - thrddemo, если установить точку останова внутри процедуры, исполняемой в потоке, после N-го шага начинается перепрыгивание с потока на поток.

← →
Пробегал2.... (2009-01-24 22:25) [3]

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

Используй например логирование для отладки.

← →
Unknown user © (2009-01-24 23:08) [4]

>Пробегал2...

Интересовался у сишников. В Visual Studio при пошаговой отладке, если отладчик зашел в поток то выполняет все его инструкции пока поток не завершит работу или программист, сделает активным другой поток из выполняющихся в данный момент. Есть такое окошко в Delphi в меню Debug Windows, называется Threads, там показаны выполняющиеся потоки и есть команда Make Current в контекстном меню. Какой в ней смысл?

← →
Kerk © (2009-01-24 23:23) [5]

D2006 меня бесила своими зависаниями во время отладки многопоточной хреновины.

← →
Unknown user © (2009-01-24 23:36) [6]

>Kerk

Вот-вот... ТО же самое наблюдал в Делфи 5. Более того такой вот код

FObject:=nil;
FObject.SomeField:=SomeValue;

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

← →
ketmar © (2009-01-24 23:57) [7]

потому что отладчик не нужен.

---
All Your Base Are Belong to Us

← →
Eraser © (2009-01-25 00:02) [8]

> [0] Unknown user © (24.01.09 22:10)

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

← →
ketmar © (2009-01-25 00:07) [9]

а я использую debuglogf (да-да, свой модуль на C %-) и не имею проблем. а при падении имею post-mortem dump, который позволяет прояснить ситуацию. интерактивный отладчик не нужен.

---
All Your Base Are Belong to Us

← →
Unknown user © (2009-01-25 00:12) [10]

>ketmar

что делает debuglogf? он может полностью заменить пошаговый отладчик? и что такое post-mortem dump?

← →
ketmar © (2009-01-25 00:13) [11]

>[10] Unknown user © (2009-01-25 00:12:00)
>что делает debuglogf
printf в лог.

>что такое post-mortem dum
после этого даже пояснять ничего не охота.

---
All Your Base Are Belong to Us

← →
Eraser © (2009-01-25 00:17) [12]

> [9] ketmar © (25.01.09 00:07)

ну логирование и трассировка это совершенно разные методы отладки. все таки 21 век на дворе, хотелось бы иметь в IDE полноценный и не глючный трассировщик.

← →
ketmar © (2009-01-25 00:19) [13]

>[12] Eraser © (2009-01-25 00:17:00)
ещё раз: в 99.(9)% случаев оно *не надо*. print + post-mortem всё решают.

а-а-а-а! забыл, извини. у вас же нет post-mortem dump"ов…

---
Do what thou wilt shall be the whole of the Law.

← →
Eraser © (2009-01-25 00:21) [14]

> post-mortem

эт что, стек вызова? есть, достаточно JCL прикрутить.

← →
ketmar © (2009-01-25 00:30) [15]

>[14] Eraser © (2009-01-25 00:21:00)
>эт что, стек вызова?
поржал, благодарю.

реквестирую ИШа, АПа или Розыча — они тоже поржут.

---
Understanding is not required. Only obedience.

← →
ДимДимыч (2009-01-25 01:24) [16]

> Пошаговая отладка невозможна

Это правда

← →
Unknown user © (2009-01-25 02:10) [17]

Интересно какие еще есть способы отладки работы потоков кроме логирования? Что скажут программисты имеющие опыт работы не только в Делфи?

← →
Игорь Шевченко © (2009-01-25 02:44) [18]

> Интересно какие еще есть способы отладки работы потоков
> кроме логирования?

Писать правильно, например. Вполне себе способ.

← →
Дмитрий С (2009-01-25 06:59) [19]

Почти всегда код, который требует отладки можно отладить в отдельном приложении или в основном потоке. А вообще, согласен с [18].

Кстати, о потоках. В дельфи поток нужно(?) запускать с помощью BeginThread из модуля system, который является оберткой Апишной функции CreateThread. Только разница в том, что Апишная требует, чтобы вызов функции потока был stdcall, а Дельфиная нет (что там в дельфи вообще по-умолчанию??). Вот такой вот глюк :(

← →
test (2009-01-25 07:28) [20]

Если у нас приложение или служба завершается аварийно, то ее содержимое памяти тоже сохраняются в файл (так называемый пользовательский дамп, user dump). Этот дамп памяти также называется постмортем дамп, и мы называем программу, которая сохраняет его - постмортем отладчик. Таких программ может быть несколько, и одна, которая указывается в реестре для выполнения, называется постмортем отладчик по умолчанию (default postmortem debugger).

http://www.dumpanalysis.org/ru/blog/index.php/2008/07/

ps
Надо бы уже примеры из Хаскела в ветках писать и ржать над всеми.
Как Задорнов: -"Ну вы тупые"

← →
KSergey © (2009-01-25 07:32) [21]

> Unknown user © (25.01.09 02:10) [17]
> Интересно какие еще есть способы отладки работы потоков
> кроме логирования?

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

По поводу методов - надо смотреть по ситуации: если беда в пределах одного потока, то можно вынести в отдельное отладочное приложение; если в межпоточном взаимодействии - то интерактивный отладчик тут тем более не в помощь, только логирование. Однако добавленное логирование может нарушить картинку и программа с логированием в конкретной ситуации начнет "работать без глюков".

← →
test (2009-01-25 07:37) [22]

KSergey © (25.01.09 07:32) [21]
Смотря как логирование строить.

← →
Alex Konshin © (2009-01-25 09:05) [23]

ODS (OutputDebugString)

← →
Unknown user © (2009-01-25 13:19) [24]

>Alex Konshin

Что это такое?

← →
Alex Konshin © (2009-01-25 13:33) [25]

Функция WinAPI для отладочной печати. Этот вывод можно увидеть в Delphi IDE, но я предпочитаю использовать DebugView
http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx
Кстати, вывод можно смотреть и на другой машине.

← →
ketmar © (2009-01-25 15:39) [26]

>[17] Unknown user © (2009-01-25 02:10:00)
>Интересно какие еще есть способы отладки работы потоков кроме логирования?
не использовать потоки вовсе.

>[19] Дмитрий С (2009-01-25 06:59:00)
>Только разница в том, что Апишная требует, чтобы вызов функции потока был
>stdcall, а Дельфиная нет (что там в дельфи вообще по-умолчанию??). Вот такой вот
>глюк :(
ты бы к генофонд заглянул, что ли… глюк — это то, что ты сюда написал.

>[20] test (2009-01-25 07:28:00)
>Если у нас приложение или служба завершается аварийно, то ее содержимое памяти
>тоже сохраняются в файл (так называемый пользовательский дамп, user dump).
значит, я этого не умею. ссылки не дашь, как это в XP сделать? а то я что-то только про свисту вижу инфу да про 2008 server. а никсы, кагбэ, уже несколько десятков лет умеют. медленно m$ списывают, медленно.

>[24] Unknown user © (2009-01-25 13:19:00)
>Что это такое?
весьма удобный инструмент.

---
Understanding is not required. Only obedience.

← →
Eraser © (2009-01-25 16:10) [27]

> [20] test (25.01.09 07:28)
> Если у нас приложение или служба завершается аварийно, то
> ее содержимое памяти тоже сохраняются в файл (так называемый
> пользовательский дамп, user dump). Этот дамп памяти также
> называется постмортем дамп, и мы называем программу, которая
> сохраняет его - постмортем отладчик. Таких программ может
> быть несколько, и одна, которая указывается в реестре для
> выполнения, называется постмортем отладчик по умолчанию
> (default postmortem debugger).

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

← →
Игорь Шевченко © (2009-01-25 16:17) [28]

> ссылки не дашь, как это в XP сделать?

"Для создания дампа нужно использовать средства библиотеки DbgHelp. А именно функцию MiniDumpWriteDump. Функция получает на вход структуру EXCEPTION_POINTERS, которая содержит контекст в котором произошло исключение"

← →
ketmar © (2009-01-25 16:38) [29]

>[28] Игорь Шевченко © (2009-01-25 16:17:00)
это чего, я *руками должен код писать*?! благодарю, это фекалия, а не инструмент.

---
Do what thou wilt shall be the whole of the Law.

← →
Игорь Шевченко © (2009-01-25 17:00) [30]

ketmar © (25.01.09 16:38) [29]

Меня крайне мало волнует, какой частью тела ты собираешься писать/не писать код. Если ты не видишь дальше собственного носа, я тебя уговаривать не собираюсь, это всего лишь говорит о твоей ограниченности.

← →
Дмитрий С (2009-01-25 17:54) [31]

>
> ты бы к генофонд заглянул, что ли… глюк — это то, что ты
> сюда написал.

Как обычно одни указания и ничего конструктивного. Даже объяснять ничего не хочу.

← →
Пробегал2.... (2009-01-25 18:06) [32]

Alex Konshin © (25.01.09 13:33) [25]
Функция WinAPI для отладочной печати. Этот вывод можно увидеть в Delphi IDE

а где в дельфи можно увидеть этот вывод? Тогда всегда DV использовал, даже не знал что в дельфе можно )

← →
Eraser © (2009-01-25 18:14) [33]

> [32] Пробегал2.... (25.01.09 18:06)

в логе выполнения процесса.

← →
Сергей М. © (2009-01-25 19:03) [34]

> Unknown user © (24.01.09 22:10)
> Пошаговая отладка невозможна

Не трынди.
Все возможно.
Проблемы только в кривых руках и отсутствии знаний

← →
Piter © (2009-01-25 23:43) [35]

Eraser © (25.01.09 18:14) [33]
в логе выполнения процесса.

это что такое?

В смысле в окошке внизу куда компилятор ошибки выводит?

← →
Unknown user © (2009-01-26 00:02) [36]

>Сергей М.

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

← →
Piter © (2009-01-26 00:11) [37]

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

← →
Unknown user © (2009-01-26 00:51) [38]

>ну почему непредсказуемо. Он переключается строго в соответствии с тем, какой поток винда сейчас выполняет

ну это для Винды предсказуемо, программист, же закономерности не видит. Он видит только, что пошаговая отладка потоков в Делфи практически невозможна. Понятное дело, что взаимодействие потоков в интерактивном отладчике я увидеть не смогу, но я на это и не надеюсь. Задача отладить основной код потока. Конечно можно вынести этот код в основной поток, но это неудобно. Visual Studio решает правильно, если интерактивный отладчик зашел в поток, то переключение между потоками надо заблокировать. И судя по команде Make Current в окне управления потоками в Делфи, так должно работать и в ней. Может я не тот дебаггер использую?

← →
Eraser © (2009-01-26 02:47) [39]

> [35] Piter © (25.01.09 23:43)

> В смысле в окошке внизу куда компилятор ошибки выводит?

да

← →
Piter © (2009-01-26 22:50) [40]

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

← →
Piter © (2009-01-26 22:51) [41]

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

>[31] Дмитрий С (2009-01-25 17:54:00)
>Как обычно одни указания и ничего конструктивного. Даже объяснять ничего не
>хочу.
*мне* кагбэ и не надо. а ты — фигню сказал.

>[30] Игорь Шевченко © (2009-01-25 17:00:00)
>Если ты не видишь дальше собственного носа, я тебя уговаривать не собираюсь, это
>всего лишь говорит о твоей ограниченности.
а может то, что я вынужден писать руками базовый код, который в нормальной системе наличествует изначально — это не я не вижу чего-то, а система уродлива? а ну как у меня всё жёстко завалилось, так, что уже и апи не позвать? чего тогда? писать свой ядерный драйвер для дампов? круто, ничего не скажешь.

---
Understanding is not required. Only obedience.

ketmar © (27.01.09 00:53) [43]

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

Это что - единственное отличие ? Больше никаких не существует и только необходимость писать N строчек кода для получения post-mortem dump является тормозом для создания кросс-платформенного приложения ?

>[44] Игорь Шевченко © (2009-01-27 13:32:00)
>Это что — единственное отличие ?
нет. но очень неприятное.

>олько необходимость писать N строчек кода для получения post-mortem dump
>является тормозом для создания кросс-платформенного приложения ?
ещё, как минимум, отсутствие в винде позикса (и fork()"а в частности). благодаря чему я не могу написать кроссплатформенный backend и прилепить к нему «родные» гуя где надо.

да даже несчастного аналога valgrind — и того нет! а если бы не портировали gcc — то и компилятора нормального не было бы.

---
Understanding is not required. Only obedience.

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

ketmar © (27.01.09 16:22) [45]

> ещё, как минимум, отсутствие в винде позикса (и fork()"а
> в частности).

Если бы у бабушки были колеса, то это была бы не бабушка, а трамвай.

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

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

> а если бы не портировали gcc — то и компилятора нормального
> не было бы.

Извини, но к gcc я за много лет так и не смог привыкнуть, потому о нормальности ничего сказать не могу. Мне от компилятора немного надо - чтобы он исходный код в объектный превратил, а большего не требуется. А с gcc почему именно в этом процессе у меня возникали проблемы.

>ketmar ©

Если ты считаешь что посмертный дамп - всеобщая панацея, то ты мнишь о себе слишком много. Более того, в подавляющем большинстве сред программирования он как зайцу пианино. Поэтому нефиг делать лицо как у лемура когда кто-то не слышал о дампе.
Хотя, конечно, каждый кто не знаком с асмом - лох, ламер и неудачник :)

>[47] Игорь Шевченко © (2009-01-27 22:17:00)
>Кстати, что интересно — за свой долгий опыт ни разу не видел реальных
>кроссплатформенных приложений, за исключением написанных на разного рода
>интерпретируемых языках.
потому что платформы, в принципе, аж две, и одна их них не держит posix. %-)

ну, и гуя — это отдельная песня, да.

>Мне от компилятора немного надо — чтобы он исходный код в объектный превратил, а
>большего не требуется.
угу. вот у m$vc с этим как раз огромные проблемы, потому что C99 мы не понимаем. а gcc — понимает, за что получает жирный респект.

>с gcc почему именно в этом процессе у меня возникали проблемы.
ну, mingw в своё время был страшен, конечно. щаз чуть получше стал.

>[48] MsGuns © (2009-01-27 22:51:00)
чего ты дёрганый такой, а? ну жил ты без этой фичи — и живи дальше, «запорожец» — тоже машина.

---
All Your Base Are Belong to Us

Не пойму одного - Торвальдз за рекламу приплачивает?

>[50] SPeller © (2009-01-28 02:14:00)
а ты думаешь, откуда у линуксоидов интернеты?

---
Do what thou wilt shall be the whole of the Law.

Тогда оно должно умереть как и весь сетевой маркетинг )

>ketmar © (28.01.09 01:57) [49]
>чего ты дёрганый такой, а? ну жил ты без этой фичи — и живи дальше, «запорожец» — тоже машина.

Я - дерганный ? :))
Я, уважаемый, было время, из этих самых "посмертных" не вылазил, ибо на ЕС ЭВМ (позже на СМ-4М) других удовлетворительных средств поиска ошибок не было.
В дельфи нынче они мне просто не нужны ибо вполне обхожусь дебаггером. Хотя, для справедливости, операционных систем не пишу :) Тут таки да, тебе не пара :)

> MsGuns (28.01.2009 9:48:53) [53]

DurdomOS

>[53] MsGuns © (2009-01-28 09:48:00)
я тоже ОС не пишу. и сидел в дельфийском отладчике, пока не перешёл сначала на writeln, потом на ОС, где есть дампы. потому что отладчик дичайше неудобен.

---
All Your Base Are Belong to Us

← →
имя (2009-02-19 14:21) [56]

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

← →
ANB (2009-02-20 13:35) [57]

Лучшее средство не наступать на грабли с потоками - стараться их не использовать.

топикстартеру: отлаживать многопоточное приложение пошаговым отладчиком - дело совершенно бестолковое. Т.к. весь кайф потоков в одновременном их исполнении, в этом же и все "глюки".
Т.е. просто надо заставить себя переходить ан следующий уровень: сначала тщательно планировать как мы разносим приложение на потоки, как будем организовывать взаимодействие между потоками, отдельно продумывая коллизии по чтению/изменению общих данных потоков, если таковое имеется.
Только после этого есть смысл начинать писать код. Причем отлаживать его пошагово - уже совершенно бесполезно; максимум что тут поможет - логи, да и то беда в том, что логирование может маскировать ошибку, т.к. выполнение команд потоков сдвинется во времени, т.е. ошибка может "исчезнуть", а вернее - просто замаскироваться. Особенно, понятно, это наглядно будет видно при применении защищенного многопоточного логирования в один файл, когда потоки из-за логирования будут подсинхронизироваться.

оказывается в эту ветку я это уже писал, сорри :)

Работа с потоками в Delphi Найти похожие ветки