pthread_create() exit with code 11

[IMB]

согласно https://stackoverflow.com/questions/7038586/return-code-from-pthread-create-is-11

the number 11 stands for EAGAIN which in turn means "The system lacked the necessary resources to create another thread, or the system-imposed limit on the total number of threads in a process PTHREAD_THREADS_MAX would be exceeded."

Но почему так происходит - предыдущие потоки не завершаются или иная причина? Для всех, я так предполагаю, потоков выполняется pthread_join(), так что они вроде как должны завершаться.
Спасибо.

[IMB]

Код: Выделить всё

# cat /proc/sys/kernel/pid_max 
32768

увеличить нельзя
при создании потоков в /proc/PID/task видно что номера увеличиваются

Код: Выделить всё

ls /proc/370/task/
1968  1971  370   567   569   578   584   587   646   648
1970  1972  549   568   577   579   586   589   647

и

Код: Выделить всё

# ls /proc/370/task/
2057  2062  2064  549   568   577   579   586   589   647
2059  2063  370   567   569   578   584   587   646   648

отсюда предположение что причина в исчерпании PID-в
отсюда наивный вопрос - разве PID-ы не должны освобождаться при pthread_join() и что я должен/могу сделать для этого?
Спасибо.

[Bizdelnick]

Значения, возвращаемые pthread_join(), проверяете?

[IMB]

Да, там всё нормально. Это Вы о зомби-процессах? top и количество процессов не отображают их.
В процессе работы приложения запустид мониторинг /proc/PID/task

Код: Выделить всё

639/ 641/ 643/ 645/ 651/ 653/ 660/ 663/ 694/ 700/
640/ 642/ 644/ 646/ 652/ 655/ 662/ 664/ 699/ 701/
1119/ 1124/ 639/  641/  643/  645/  651/  653/  662/  664/
1123/ 1125/ 640/  642/  644/  646/  652/  655/  663/
1728/ 1737/ 639/  641/  643/  645/  651/  653/  662/  664/
1736/ 1738/ 640/  642/  644/  646/  652/  655/  663/
..............
30570/ 30576/ 639/   641/   643/   645/   651/   653/   662/   664/
30575/ 30577/ 640/   642/   644/   646/   652/   655/   663/
31157/ 31161/ 639/   641/   643/   645/   651/   653/   662/   664/
31160/ 31162/ 640/   642/   644/   646/   652/   655/   663/
31755/ 31760/ 639/   641/   643/   645/   651/   653/   662/   664/
31759/ 31761/ 640/   642/   644/   646/   652/   655/   663/
32350/ 32355/ 639/   641/   643/   645/   651/   653/   662/   664/
32354/ 32356/ 640/   642/   644/   646/   652/   655/   663/
479/ 484/ 639/ 641/ 643/ 645/ 651/ 653/ 662/ 664/
483/ 485/ 640/ 642/ 644/ 646/ 652/ 655/ 663/
1098/ 1103/ 639/  641/  643/  645/  651/  653/  662/  664/
1102/ 1104/ 640/  642/  644/  646/  652/  655/  663/

несколько раз "прокрутилось" и завершилось с озвученной ошибкой

[Bizdelnick]

Значит, либо не все треды ждёте, либо не все они завершаются. gdb в помощь.
set print thread-events
После ошибки info threads
И так далее.

[IMB]

После ошибки через некоторое время следует падение проверка идентификатора потока
Количество потоков по мнению системы стабильно, дополнительно контроливал через /proc/PID/status.
Но вс любом случае спасибо, посмотрю, к сожалению использовать gdb не предстявляется возможным по причине линковки с закрытой либой которая препятствует этому, так что могу только анализировать core-file.

[Bizdelnick]

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

Чтобы не реверсили, что ли? Очень дружелюбный подход, ничего не скажешь.

могу только анализировать core-file

Ну хоть на нём info threads, может быть, что-то подскажет насчёт незавершённых тредов.

[IMB]

Похоже починялось.
vendor SDK написан не особо качественно, китайцы делают упор на скорость , и для предотвращения работы с неверным pthread_t, они его сравнивали через != местами, был добавлен вызов pthread_kill(id, 0) перед pthread_join(), что вроде как чуток поправило проблему с падениями. Потом, как появилось время и возможность, vendor SDK был более пристально изучен, что конечно не исключает того, что не все проблемы были выявлены, но вызов pthread_kill не был убран, соотвественно если поток завершался до него, то он возвращал ошибку и pthread_join не вызывался.
Вот как-то так, используется gcc-4.9.