Я тестирую порт Mac OS X своего многопоточного сервера. Он запускается, но умирает в 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
РЕДАКТИРОВАТЬ: Я считаю, что это связано с ошибкой в ostringstream с конфигурацией XCode 3.2 DEBUG. См. проблему ostringstream с int в c ++
