Почему повисли все потоки из ThreadPool?

Question

[Karnah]

Всем доброго дня.
Есть приложение WPF, которое часто использует пул потоков. При одном из запусков приложения закончился пул потоков и оно зависло. В дампе видно, что 931 поток имеют стектрейс:

ntdll.dll!_NtWaitForSingleObject@12()
KERNELBASE.dll!WaitForSingleObjectEx()
kernel32.dll!@BaseThreadInitThunk@12()
ntdll.dll!__RtlUserThreadStart()
ntdll.dll!__RtlUserThreadStart@8()

Стекйтрейс остальных потоков (включая главный) оканчиваются на ntdll.dll!_NtWaitForMultipleObjects@20(), ntdll.dll!_NtWaitForSingleObject@12(), ntdll.dll!_NtDelayExecution@8() и ntdll.dll!_NtClose@4(). Судя по логам потоки были забиты не сразу, а постепенно - это заняло больше 20 минут. Баг единичный, но очень хотелось бы разобраться. Что это могло быть и как можно получить больше информацию о проблеме?
Заранее спасибо!

Comments

[Петр]

"Есть приложение WPF, которое часто использует пул потоков." как использует? Явно не верно использует что было создан 931 поток и все повисли на Event обьекте.

[#]

исходники в студи!

если приложение чужое - к автору!

[Karnah]

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

[Hemul GM]

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

[Hemul GM]

Всё, что мы можем сказать, это то, что один из потоков ждёт вероятно главный поток, который уже завершается и не хочет никого пускать. А главный поток, через кривой механизм ждет, пока все потоки завершатся.

Answer 1

[#]

Karnah,

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

как бы это по деликатнее..

помним, скорбим (с)

но раз уж вы задаете вопрос в теге C# - есть один ход:
- вносите отладочное логгирование
- везде где запускаете поток (там же можно генерить уникальный id, хоть guid)
- везде где успешно завершается поток (именно тут id был бы ценен)
- набейте морду/напишите докладную/высскажете все что думаете, кодеру, за выпуск в продакшен такого сырца

.. а вы что хотели?

upd по мотивам каментов (обновлено)

@Karnah,

Хотелось бы комментарий по стектрейсу - он вообще не затрагивает код проекта. В какой ситуации это возможно?

повторюсь - что у вас происходит, остается только телепатировать

В дампе видно

у вас BSOD что ли?
1 - а чем смотрите? не все инструменты покажут полный стек. в этой части, возможно и есть выбор инструментов. только это не про C#
2 - дамп то полный? может минидамп?
3 - стек управляемого кода, искать в дампе, еще сложнее, чем дебажить ваш проект. просто по тому, что его там может не быть вообще. что бы он был - ваше приложение должно успеть поймать исключение. но если у вас BSOD - это значит операционка крешится раньше управляемого кода.. понимаете?
4 - именно по этому, если у вас есть есть сорцы или автор - только основная часть ответа и дебаг
5 - WPF в принципе не генерит потоки сам. пока кодер не начнет. по этому снова - без сорцов, без объяснения что у вас там вообще твориться? ваш вопрос подобен поискам дерева и мужика из старого, популярного кино

Karnah,

То есть ожидался ответы вида: "стектрейс выглядит странно,

ни чего странного для

таймеры .. и бесконечные циклы..

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

Comments

[Karnah]

Хотелось бы комментарий по стектрейсу - он вообще не затрагивает код проекта. В какой ситуации это возможно?

[#]

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

в контексте C# я уже ответил на столько, на сколько можно ответить о "черном ящике" (без кода и тд)

[Karnah]

1. Стек смотрю с помощью Visual Studio, окно Parallel Stacks. Подгружены все библиотеки + скомпилированное приложение + исходники.
2. Дамп создаётся с помощью ProcDump. Судя по размеру, это действительно минидамп
3. BSOD не было, приложение повисло, это поймал ProcDump.
5. Потоки генерируются вручную. Их есть три вида: ради операций UI (создаются только через фабрику, жестко отслеживаются), таймеры (используется безопасная реализация, когда следующий запускается только после завершения выполнения кода, в логах нет связанных с ними проблем) и бесконечные циклы мониторинга (их ограниченное количество, они хорошо видны в списке потоков). Именно тот факт, что нет видимых проблем + странный стектрейс побудил задать этот вопрос.

На самом деле, я умолчал, что у нас были проблемы очень похожие проблемы с Nlog, но там был четко прослеживался стектрейс:


Соответственно, хотелось понять как лучше изучить дамп, и выяснить связаны ли эти две проблемы.

[#]

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

надо пояснить зачем? - что бы знать какие потоки плодятся и не завершаются корректно

[#]

Karnah,

3. BSOD не было, приложение повисло

отлично!
что такое висяк?
что такое висяк, чаще всего? - зацикливание, не так ли?

и бесконечные циклы мониторинга

в качестве продолжения, это звучит просто как музыка - бесконечные циклы!!! (чего именно, это даже не важно)

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

[Karnah]

#, забить все использования потоков логами хотелось бы оставить как крайнюю меру. К тому же абсолютно никак не поможет в случае проблем в сторонней библиотеке. Разве что дать чуть больше уверенности, что ищем не там, где нужно.
Изначально требовалась помощь с исследованием именно этого конкретно стектрейса конкретного дампа. У нас уже есть зафиксированный случай, когда повисание потоков происходит в сторонней библиотеке, поэтому хотелось бы определить связаны они или нет.
То есть ожидался ответы вида: "стектрейс выглядит странно, но он происходит если {причина}", "стектрейс криво отображается из-за инструмента, попробуйте {имя_инструмента}", "стектрейс кривой из-за дампа, при поиске проблемы не поможет". Все же комментарии и ответы выглядят как "никогда в жизни не видел такой стектрейс, поэтому сами виноваты, что плодите потоки, вот вам очевидные способы проверить это". Прошу прощения, что не смог сразу корректно сформулировать вопрос, так как не ждал таких ответов.

[#]

Karnah, но тогда вам не в тег C#. по тому что вы ищете совета по стектрейсу, который уже явно очень далеко от управляемого кода

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

повисание потоков происходит в сторонней библиотеке

у меня вызывает только один рефлекс - библиотеку(и) в студию!
вру, еще один - обращайтесь к разрабам библиотек!

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

[#]

Karnah, и еще раз повторюсь - у вас явно плодятся потоки, тогда, когда не надо. при этом не закрываются когда надо. а уж в вашем коде, или в стороннем.. вам виднее upd возможно, но вопросу и каментам, это не очевидно

[#]

Karnah, а еще вы не хотите заниматься отладкой и анализом.. тех же логов

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

[#]

Karnah,

То есть ожидался ответы вида: "стектрейс выглядит странно,

ни чего странного для

таймеры .. и бесконечные циклы..

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

[Karnah]

#, чуть выше упоминал, удивительно, но это NLog. AsyncTargetWrapper - это их класс.
По поводу бесконечных циклов - требуется низкоуровневый мониторинг за устройствами. Это специфика приложения.
По поводу того, что они плодятся и не закрываются - тоже прекрасно понимаю.
Не сразу весь пул потоков исчезает, а постепенно - значит после запроса, поток должен начать выполняться. Если бы он завис в середине метода, то это показал бы стектрейс потока. А так складывается впечатление, что вместо того, чтобы вернуться в пул, он блокируется где-то на уровне системных библиотек. UI поток практически всё время свободен, так что они точно не пытаются в него попасть.
И опять-таки, стектрейсы таймеров и бесконечных циклов прекрасно видны и доступны для анализа.

В любом случае, большое спасибо.

[#]

Karnah, допустим у вас жутко секретная специфика. ок

По поводу того, что они плодятся и не закрываются - тоже прекрасно понимаю.
Не сразу весь пул потоков исчезает, а постепенно - значит после запроса, поток должен начать выполняться. Если бы он завис в середине метода, (1) то это показал бы стектрейс потока. А так складывается впечатление, что вместо того, чтобы вернуться в пул(2), он блокируется где-то на уровне системных библиотек (3). UI поток практически всё время свободен, так что они точно не пытаются в него попасть.

1 - а ни кто и не говорит что метод крешится. настаиваю
2 - теплее. да он не возвращается в пул
3 - домыслы. как раз это и есть то место, где не надо фантазировать, а надо тестировать. вы упоминаете 931 поток. а это не миллиард.

В любом случае, большое спасибо.

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