- 2009-05-13 (Wed) 17:17
- Google OSS

gflagsとglogの組み合わせだと、初期化時にデッドロックするケースが有る模様 @ RHEL5。ソースコードは以下のような感じ。
#include <glog/logging.h>
#include <google/gflags.h>
#include <iostream>
using namespace std;
int main(int argc, char **argv)
{
google::InitGoogleLogging(argv[0]);
google::InstallFailureSignalHandler();
google::ParseCommandLineFlags(&argc, &argv, true);
cout << "hogehoge" << endl;
}
リンクの順番によって、デッドロックしたりしなかったり。
$ g++ test.cpp -lgflags -lglog; ./a.out hogehoge $ g++ test.cpp -lglog -lgflags; ./a.out ^C # deadlock occurs
gdbするとこんな感じ。
(gdb) bt #0 0x007c8402 in __kernel_vsyscall () #1 0x00787ceb in pthread_rwlock_wrlock () from /lib/libpthread.so.0 #2 0x00aaed87 in Mutex::Lock () from /opt/sedue/lib/libglog.so.0 #3 0x00aaedc3 in MutexLock::MutexLock () from /opt/sedue/lib/libglog.so.0 #4 0x00bb9034 in google::(anonymous namespace)::FlagRegistry::GlobalRegistry () from /opt/sedue/lib/libgflags.so.0 #5 0x00bbff49 in google::ParseCommandLineFlagsInternal () from /opt/sedue/lib/libgflags.so.0 #6 0x00bc0196 in google::ParseCommandLineFlags () from /opt/sedue/lib/libgflags.so.0 #7 0x080488a3 in main ()
-g付き。
(gdb) bt #0 0x003fe402 in __kernel_vsyscall () #1 0x002d4ceb in pthread_rwlock_wrlock () from /lib/libpthread.so.0 #2 0x00ca0d87 in Mutex::Lock (this=0x44e904) at src/base/mutex.h:171 #3 0x00ca0dc3 in MutexLock (this=0xbfa390cc, mu=0x44e904) at src/base/mutex.h:217 #4 0x00435034 in GlobalRegistry () at src/gflags.cc:675 #5 0x0043bf49 in ParseCommandLineFlagsInternal (argc=0xbfa391d4, argv=0xbfa391d0, remove_flags=true, do_report=true) at src/gflags.cc:1825 #6 0x0043c196 in google::ParseCommandLineFlags (argc=0xbfa391d4, argv=0xbfa391d0, remove_flags=true) at src/gflags.cc:1855 #7 0x0804d9b3 in main (argc=1, argv=Cannot access memory at address 0x84 ) at hoge.cpp:111
初期化順序に問題が有る気がするんだけど、ちょっとソース見た感じでは分からなかったので、バグ報告的エントリ。
Similar Posts:
- Newer: gflags + glogでdeadlock? (2)
- Older: n日前より古いファイルを消す
Comments:7
- shinh 09-05-14 (Thu) 1:34
-
見ますです。 glog と gflags のバージョンは何でしょうか?
- kzk 09-05-14 (Thu) 1:49
-
おお、ありがとうございます。
glog 0.2.1 (+例のパッチ)
gflags 1.1です。
- shinh 09-05-14 (Thu) 15:05
-
情報ありがとうございます。
なんか相談しているとその相手が有力そうな仮説を神技的に思いついてくれたのですが、なにかしら手元に再現する環境がないのが大変な感じです。その仮説によると GCC のバージョンが影響しそうな気がするんですが、教えていただけますでしょうか。あとできれば libgflags.so に対して objdump -S や nm した結果とかをいただけるとうれしい感じです。というかもし可能なら、 libgflags.so や libglog.so 、最小結果でのバイナリとかをいただけると調べられてありがたいのですが。 - kzk 09-05-14 (Thu) 23:52
-
ありがとうございます。shinh先生がログインできる環境を用意させて頂きますので、しばらくお待ちください。
- shinh 09-05-16 (Sat) 0:13
-
うへ、そこまでしていただけるくらいなら申し訳ないので自力で CentOS を Xen で入れますですよ。ちなみにその仮説ってのは Mutex::Unlock() だけ inline 化されてるのではないか、というものでした。それがあってるかどうかは objdump 見ればわかるはずなのでそれだけでもとりあえず十分ではありますです。
- kzk 09-05-16 (Sat) 4:42
-
あ、了解しました。てか、その仮説思いついた人、神ですね…ちょっと来週から日本を離れてしまうので、人に頼んでおきます。少しお待ちください、すません。
- shinh 09-05-20 (Wed) 1:04
-
神です。暇な時に雑談としてコードも見せず状況を説明しただけで思いつきました。それはそうと、コンパイラによってコード重複がちょっと出ちゃうけど、今後問題が起きないようにサックリなおすために anonymous namespace でくるんじゃおうということになりました。たぶん大丈夫だと思いますが、一応おてすきの時にでも anonymous namespace でも OK かチェックしていただけますでしょうか。重ねがさねありがとうございますです。
Trackbacks:0
- Trackback URL for this entry
- http://kzk9.net/blog/2009/05/deadlock_with_gflags_and_glo.html/trackback
- Listed below are links to weblogs that reference
- gflags + glogでdeadlock? from moratorium
