6

だから私は散発的にフリーズしているかなり実質的なプログラムを持っています。
このプログラムは、Qt、オープン シーン グラフ、Google ロギングを使用します。このフリーズは、Google ログの印刷中に発生します。プログラム自体が大量のデバッグ情報を出力しています。gdb-server 経由でプログラムに接続できました。これがスタック トレースです。

#0  0x000000397ac0e030 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:82
#1  0x00007f5eecb74aeb in google::LogMessage::SendToLog() () from /lib64/libglog.so.0
#2  0x00007f5eecb71fc7 in google::LogMessage::Flush() () from /lib64/libglog.so.0
#3  0x00007f5eecb721a9 in google::LogMessage::~LogMessage() () from /lib64/libglog.so.0
#4  0x00000000004874a6 in LSDB::process (this=0x242d918, lsp=0x25f9200, circuit=0x24c7af0) at ../src/model/trill/LSDB.cpp:481
#5  0x00000000004a0f6f in Circuit::rx (this=0x24c7af0, eth=0x246fdf0) at ../src/model/trill/Circuit.cpp:355
#6  0x000000000045c950 in Circuit::qt_static_metacall (_o=0x24c7af0, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0x7fffaade95a0)
    at ../src/model/trill/Circuit.moc.cpp:55
#7  0x000000398798cb9f in QMetaObject::activate (sender=0x2470140, m=<optimized out>, local_signal_index=<optimized out>, argv=0x7fffaade95a0)
    at kernel/qobject.cpp:3547
#8  0x0000000000459610 in FramePublisher::subscription (this=0x2470140, _t1=0x246fdf0) at ../src/model/system/FramePublisher.moc.cpp:98
#9  0x000000000047c0d6 in FramePublisher::rx (this=0x2470140, frame=0x246fdf0) at ../src/model/system/FramePublisher.hpp:21
#10 0x000000000047bedb in EthernetPort::rx (this=0x246d7a0, frame=0x25a4180) at ../src/model/system/EthernetPort.cpp:81
#11 0x000000000045a208 in EthernetPort::qt_static_metacall (_o=0x246d7a0, _c=QMetaObject::InvokeMetaMethod, _id=1, _a=0x7fffaade9810)
    at ../src/model/system/EthernetPort.moc.cpp:51
#12 0x000000398798cb9f in QMetaObject::activate (sender=0x246d7a0, m=<optimized out>, local_signal_index=<optimized out>, argv=0x7fffaade9810)
    at kernel/qobject.cpp:3547
#13 0x0000000000459ddc in Port::rx (this=0x246d7a0, _t1=0x25a4180) at ../src/model/system/Port.moc.cpp:110
#14 0x00000000004803a6 in Port::inject (this=0x246d7a0, frame=0x25a4180) at ../src/model/system/Port.cpp:25

...

フリーズ自体が で発生していることに注意してください__write_nocancel。実行中のスレッドは 1 つだけです...

(gdb) 情報スレッド Id ターゲット Id フレーム
* 1 スレッド 21507 0x000000397ac0e030 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:82

フリーズの原因について何か考えはありますか？他に役立つ情報を教えてください。

4

1 に答える 1

3

出力が stderr に書き込まれているとおっしゃいました。stderr が別のプロセスによって常に読み取られていない場合は、I/O バッファーがいっぱいになっている可能性があるため、さらに書き込む前に stderr が読み取られるのを待機しています。

プロセス A が stderr に書き込みを行っており、プロセス B が通常通り stderr から読み取りを行っているが、現在プロセス A を待機している場合、デッドロックが発生する可能性があります。あなたの場合、stderrへの書き込みが大きすぎる場合にのみデッドロックが発生する可能性があります。これは、小さな書き込みがすぐに成功し、プロセスAが解放され、プロセスBが解放されてstderrから読み取られるためです。

これは私の推測ですが、一般的には、バッファがいっぱいになるのを待っていることが問題だと思います。

于 2013-06-12T23:32:39.727 に答える