Le port de Mac OS X se bloque dans pthread_setspecific dans glibstdC++ vsnprintf - comment résoudre les problèmes?

Question

Je teste un port Mac OS X de mon serveur multithread. Il démarre, mais il meurt dans vsnprintf peu de temps après que la première requête client est prise par un thread de travail.

Il semble que vsnprintf tente de manipuler de la mémoire locale de thread avec pthread_setspecific. Cela déréférences un mauvais pointeur. Ensuite, gdb piège un appel dlopen, reçoit une erreur et meurt en essayant de formater son propre message d'erreur. Parce que, pour formater l'erreur, il faut configurer une mémoire locale de thread! Avant cela, mon propre code utilisait avec succès pthread_create_key, pthread_getspecific et pthread_setspecific. J'ai soigneusement connecté mes propres accès et je ne pense pas qu'ils corrompent quoi que ce soit.

Est-il possible qu'une partie statique de la glibstdC++ n'ait pas été initialisée à temps? Comment puis-je le dire?

En outre, j'ai utilisé le g ++ -pthread pour la compilation et la liaison, mais je ne vois pas de libpthread dans mon manifeste exécutable.

otool -L myExecutable 

libboost_thread-xgcc40-mt-1_39.dylib (compatibility version 0.0.0, current version 0.0.0) 
/Users/eolson//lib/libgsl.0.dylib (compatibility version 14.0.0, current version 14.0.0) 
/Users/eolson//lib/libgslcblas.0.dylib (compatibility version 1.0.0, current version 1.0.0) 
/Users/eolson/mico-2.3.12/lib/libmico2.3.12.dylib (compatibility version 0.0.0, current version 0.0.0) 
/usr/local/lib/libModelsCorba.dylib (compatibility version 1.0.0, current version 1.0.0) 
/usr/local/lib/libModelsBigLibrary.dylib (compatibility version 1.0.0, current version 1.0.0) 
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) 
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) 
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) 

Est-ce que quelqu'un a une idée de comment déboguer cela?

Trace de la pile:

[Switching to process 37784] 
Program received signal: “EXC_BAD_ACCESS”. 
[Switching to process 37784] 
sharedlibrary apply-load-rules all 
Data Formatters temporarily unavailable, will re-try after a 'continue'. (The program being debugged was signaled while in a function called from GDB. 
GDB remains in the frame where the signal was received. 
To change this behavior use "set unwindonsignal on" 
Evaluation of the expression containing the function (dlopen) will be abandoned.) 
(gdb) where 

#0 0x9232f03b in pthread_setspecific() 
#1 0x9232efe6 in getPerThreadBufferFor_dlerror() 
#2 0x8fe0b0cd in __dyld_dlopen() 
#3 0x9232ef48 in dlopen() 
#4 <function called from gdb> 
#5 0x9232f03b in pthread_setspecific() 
#6 0x9233ed64 in __Balloc_D2A() 
#7 0x9233eb92 in __d2b_D2A() 
#8 0x9233dc5e in __dtoa() 
#9 0x92335975 in __vfprintf() 
#10 0x92355886 in vsnprintf() 
#11 0x96eb526b in std::__convert_from_v() 
#12 0x96eaeb5e in std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_insert_float<double>() 
#13 0x96eaedb4 in std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::do_put() 
#14 0x96ea9583 in std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::put() 
#15 0x96eb79dd in std::ostream::_M_insert<double>() 
#16 0x012db6a8 in MyCode ... 

code

qui a déclenché l'accident:

std::ostringstream buf; 
buf << myObjectWithOutputOperator << endl; 
double x = 1; 
buf << "x: " << x << endl; // crashes during __vfprintf 

EDIT: Je pense que cela est lié au bogue dans ostringstream avec XCode 3.2 Configuration DEBUG. Voir ostringstream problem with int in c++

Answer 1

Mac OS X n'utilise pas de libpthread distinct. Toutes les fonctions pthread sont libSystem:

$ nm -g /usr/lib/libSystem.dylib | grep ' _pthread_' | wc -l 
    113 

Est compilation sans _GLICXX_DEBUG=1 défini résoudre le problème, comme le suggère la question liée dans votre édition?