1

マルチスレッド サーバーの Mac OS X ポートをテストしています。起動しますが、最初のクライアント要求がワーカー スレッドによって取得された直後に、vsnprintf で終了します。

vsnprintf が pthread_setspecific で一部のスレッド ローカル メモリを操作しようとしているようです。これは不正なポインターを逆参照します。次に、gdb は dlopen 呼び出しをトラップし、エラーを取得して、独自のエラー メッセージをフォーマットしようとして停止します。エラーをフォーマットするには、スレッド ローカル メモリを設定する必要があるためです。

これ以前は、私自身のコードで pthread_create_key、pthread_getspecific、および pthread_setspecific を正常に使用していました。私は自分のアクセスを注意深く記録しましたが、それらが何かを破壊しているとは思いません。

glibstdc++ の一部の static が時間通りに初期化されていない可能性はありますか? どうすればわかりますか?

また、コンパイルとリンクに 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

編集:これは、XCode 3.2 DEBUG 構成の ostringstream のバグに関連していると思います。C ++でのintのostringstreamの問題を参照してください

4

1 に答える 1

0

Mac OS X は別のlibpthread. すべての pthread 関数は次の場所にありlibSystemます。

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

_GLICXX_DEBUG=1編集にリンクされている質問で示唆されているように、定義せずにコンパイルすると問題が解決しますか?

于 2011-07-02T17:04:00.147 に答える