2010-01-21 5 views
0

J'ai un programme qui déclenche et détruit plusieurs threads tout au long de sa vie. Tout fonctionne bien pendant un certain temps, mais finalement, je reçois la trace de pile de vidage de noyau suivante.Renforcer les threads au démarrage

#0 0x009887a2 in _dl_sysinfo_int80() from /lib/ld-linux.so.2 
#1 0x007617a5 in raise() from /lib/tls/libc.so.6 
#2 0x00763209 in abort() from /lib/tls/libc.so.6 
#3 0x003ec1bb in __gnu_cxx::__verbose_terminate_handler() from /usr/lib/libstdc++.so.6 
#4 0x003e9ed1 in __cxa_call_unexpected() from /usr/lib/libstdc++.so.6 
#5 0x003e9f06 in std::terminate() from /usr/lib/libstdc++.so.6 
#6 0x003ea04f in __cxa_throw() from /usr/lib/libstdc++.so.6 
#7 0x00d5562b in boost::thread::start_thread() from /h/Program/bin/../lib/libboost_thread-gcc34-mt-1_39.so.1.39.0 

Au début, je fils fuite, et compris le noyau était dû à frapper une limite maximale du nombre de threads en cours, mais maintenant il semble que ce problème se produit même quand je ne le fais pas. Pour référence, dans le noyau ci-dessus, 13 threads actifs étaient en cours d'exécution.

J'ai fait quelques recherches pour essayer de comprendre pourquoi start_thread serait au cœur, mais je n'ai rien trouvé. Quelqu'un a des idées?

+0

Parcourez le code dans le débogueur? – jalf

Répondre

2

start_thread lève une exception non interceptée, voir quelles exceptions peuvent start_thread lancer et placer un catch autour d'elle pour voir quel est le problème.

+0

Après avoir creusé, il semble que thread_resource_error est une exception qui peut être levée. Si je ne fuis pas de fils, pourquoi cela serait-il jeté? –

+0

Est-ce que cette exception a été interceptée par vous maintenant? Il se peut que vous manquiez de mémoire pour les piles de threads ou que vous manquiez de descripteurs de fichiers. Ou peut-être que ces discussions qui sont déjà terminées ne libèrent pas les ressources jusqu'à ce que vous les «rejoignez» ou que le programme se termine et que vous ne le fassiez pas ... –

0

Quelles sont les valeurs véhiculées par thread_resource_error? Il semble que vous pouvez appeler native_error() pour le savoir.

Comme il s'agit d'un wrapper autour de pthreads, il n'y a que quelques possibilités - EAGAIN, EINVAL et EPERM. Il semble que boost ait des exceptions qu'il devrait lancer pour EINVAL et EPERM - c'est-à-dire unsupported_thread_option() et thread_permission_error(). Cela revient à peu près à EAGAIN, donc je revérifierais que vous ne dépassez pas vraiment les limites du système sur le nombre de threads. Vous êtes sûr que vous vous joignez à eux, ou s'ils sont détachés, ils sont vraiment partis?