2

_dl_sysinfo_int80（）の呼び出しでハングしているマルチスレッドアプリケーションがあります。gdbによると、すべてのスレッドがこの呼び出しでスタックしています。

スタックトレースの一番上は次のようになります。

#0  0x002727a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x004f23de in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0
#2  0x004ef00b in _L_mutex_lock_35 () from /lib/tls/libpthread.so.0
#3  0x092828ac in construction vtable for std::ostream-in-std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> > ()

これを引き起こしている可能性のあるアイデアはありますか？

4

3 に答える 3

1

int 80は、カーネルレベルのシステムコールを行うためのソフトウェア割り込みです。私の推測では、pthreadはハングしているカーネルへの呼び出しを行っています。すべてのスレッドが次のようにミューテックスでハングする理由はいくつか考えられます
。-ミューテックスは、ロックを解除せずに終了した別のスレッドによってロックされています
-ミューテックスは、ロックするために入力しているスレッドの1つによってロックされています再帰的であると宣言されていません
-ミューテックスはまったく初期化されませんでした
-ミューテックスは、不正なポインタ、スタックの問題、その他の一般的なメモリの破損によって破損しています。

于 2008-11-20T01:47:55.640 に答える
0

SoapBoxは正しいです-コールスタックのカーネルの半分を把握し、実際にブロックしているものを見つけるには、カーネルデバッガーを接続する必要があります

于 2008-11-20T02:22:31.623 に答える
0

glibc のソース コードをざっと見てみると、次のことがわかりました。

  • _dl_sysinfo_int80すでに述べた別の答えとして、int $0x80（カーネルへの呼び出し）への呼び出しです。
  • __lll_mutex_lock_waitfutex実装の半分のユーザー空間の機能の 1 つと思われます。

これは、そのスタック トレースまたは類似のスレッドでブロックされたすべてのスレッドが、実際にはある種の pthread 同期オブジェクト (おそらく pthread ミューテックス) を待っていることを意味します。@SoapBoxの回答に示されているすべての理由が原因である可能性があります。

select が壊れている疑いがない限り、そのシステム コールのカーネル側を見る必要はありません。

于 2008-11-20T13:23:52.553 に答える