Я тестирую порт Mac OS X моего многопоточного сервера. Он запускается, но он умирает в vsnprintf вскоре после того, как первый запрос клиента занят рабочим потоком.Сбой Mac OS X в pthread_setspecific в glibstdC++ vsnprintf - как устранить неполадки?
Похоже, что vsnprintf пытается манипулировать некоторой локальной памятью потока с помощью pthread_setspecific. Это разыгрывает плохой указатель. Затем gdb прерывает вызов dlopen, получает ошибку и умирает, пытаясь отформатировать собственное сообщение об ошибке. Поскольку для форматирования ошибки необходимо настроить некоторую поточную локальную память!
До этого мой собственный код успешно использовал pthread_create_key, pthread_getspecific и pthread_setspecific. Я забрал свой собственный доступ тщательно, и я не думаю, что они что-то развращают.
Возможно ли, что некоторое статическое значение в glibstdC++ не было инициализировано вовремя? Как я могу сказать?
Кроме того, я использовал g ++ -pthread для компиляции и компоновки, но я не вижу libpthread в своем исполняемом манифесте.
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)
Есть ли у кого-нибудь идеи, как отлаживать это дальше?
Стек след:
[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 ...
код, который вызвал сбой:
std::ostringstream buf;
buf << myObjectWithOutputOperator << endl;
double x = 1;
buf << "x: " << x << endl; // crashes during __vfprintf
EDIT: Я считаю, что это связано с ошибкой в ostringstream с XCode 3.2 конфигурации DEBUG. См. ostringstream problem with int in c++
Действительно ли x не задано значение? – Mark
Извините, я упрощал. Да, x = 1 перед сбоем. printf был бы сомнительным, если бы x не были инициализированы! Кроме того, код был развернут в Linux некоторое время, поэтому я ищу конкретные проблемы с Mac OS X. –