I'm testing a Mac OS X port of my multithreaded server. It starts up, but it dies in vsnprintf soon after the first client request is taken by a worker thread.
It seems that vsnprintf is trying to manipulate some thread local memory with pthread_setspecific. This dereferences a bad pointer. Then, gdb traps a dlopen call, gets an error, and dies trying to format its own error message. Because, to format the error, it needs to set up some thread local memory!
Prior to this, my own code successfully used pthread_create_key, pthread_getspecific, and pthread_setspecific. I logged my own accesses carefully and I don't think they are corrupting anything.
Is it possible that some static in glibstdc++ has not been initialized on time? How can I tell?
Also, I used the g++ -pthread for compiling and linking, but I don't see a libpthread in my executable manifest.
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)
Does anyone have an idea how to debug this further?
Stack trace:
[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 that triggered the crash:
std::ostringstream buf;
buf << myObjectWithOutputOperator << endl;
double x = 1;
buf << "x: " << x << endl; // crashes during __vfprintf
EDIT: I believe this is related to the bug in ostringstream with XCode 3.2 DEBUG configuration. See http://stackoverflow.com/questions/1854113/ostringstream-problem-with-int-in-c