はい、この質問は以前に尋ねられましたが、答えを読んでもあまり気づかされませんでした。
数日使用するとクラッシュするCプログラムを書きました。重要な点は、すべてが正しく設定されていても、コアファイルは生成されないことです(core_pattern、ulimit -c unlimitedなど。kill-SIGQUITでコアダンプを正常にトリガーできます)。
プログラムはそれが行ったことを広範囲にログに記録しますが、ログのクラッシュについてのヒントはありません。クラッシュ時(またはそれ以前)に表示されるメッセージは次のとおりです。
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
after 2322 requests (2322 known processed) with 0 events remaining.
だから2つの質問:-コアダンプなしでプログラムがクラッシュする($?= 1を返す)のはどうして可能ですか。 -このエラーメッセージとは何ですか?
システムはRedHat Enterprise 6.4です
編集:atexit()コールバック内からabort()を呼び出すことにより、コアダンプを強制的に管理することができました。
(gdb) bt
#0 0x00bc8424 in __kernel_vsyscall ()
#1 0x0085a861 in raise () from /lib/libc.so.6
#2 0x0085c13a in abort () from /lib/libc.so.6
#3 0x0808f5cf in Unexpected () at MyCode.c:1378
#4 0x0085de9f in exit () from /lib/libc.so.6
#5 0x00c85701 in _XDefaultIOError () from /usr/lib/libX11.so.6
#6 0x00c85797 in _XIOError () from /usr/lib/libX11.so.6
#7 0x00c84055 in _XReply () from /usr/lib/libX11.so.6
#8 0x00c68b8f in XGetImage () from /usr/lib/libX11.so.6
#9 0x004fd6a7 in ?? () from /usr/local/lib/libcvi.so
#10 0x00478ad5 in ?? () from /usr/local/lib/libcvi.so
...
#29 0x001eed9d in ?? () from /usr/local/lib/libcvi.so
#30 0x001eee41 in RunUserInterface () from /usr/local/lib/libcvi.so
#31 0x0808fab4 in main (argc=2, argv=0xbfbdc984) at MyCode.c:1540
誰でもこのX11の問題について教えてくれますか? libcvi.soは私のものではなく、MyCode.c(LabWindows/CVI)のみです。
編集2014-12-05:これはさらに正確なバックトレースです。 X11では間違いなく事態が発生しますが、私はX11プログラマではないため、提供されたラインからXのソースコードを見ると、Xサーバー(?)が一時的に利用できないことだけがわかります。一時的なものである場合、このエラーを無視するように単純に指示する方法はありますか?
#4 0x00965eaf in __run_exit_handlers (status=1) at exit.c:78
#5 exit (status=1) at exit.c:100
#6 0x00c356b1 in _XDefaultIOError (dpy=0x88aeb80) at XlibInt.c:1292
#7 0x00c35747 in _XIOError (dpy=0x88aeb80) at XlibInt.c:1498
#8 0x00c340a6 in _XReply (dpy=0x88aeb80, rep=0xbf82fa90, extra=0, discard=0) at xcb_io.c:708
#9 0x00c18c0f in XGetImage (dpy=0x88aeb80, d=27263845, x=0, y=0, width=60, height=20, plane_mask=4294967295, format=2) at GetImage.c:75
#10 0x005f46a7 in ?? () from /usr/local/lib/libcvi.so
対応する行:
XlibInt.c: _XDefaultIOError()
1292: exit(1);
XlibInt.c: _XIOError
1498: _XDefaultIOError(dpy);
xcb_io.c: _XReply()
708: if(!reply) _XIOError(dpy);
GetImage.c: XGetImage()
74: if (_XReply (dpy, (xReply *) &rep, 0, xFalse) == 0 || ...
OK、私はようやく原因(National Instrumentsの誰かに感謝)、より良い診断と回避策を見つけました。
このバグはlibxcbの多くのバージョンにあり、数年前から知られている32ビットのカウンターロールオーバーの問題です。 https://bugs.freedesktop.org/show_bug.cgi?id=71338
Libxcbのすべてのバージョンが影響を受けるわけではありませんlibxcb-1.9-5は影響を受けますが、libxcb-1.5-1は影響を受けません。バグリストから、64ビットOSは影響を受けないはずですが、少なくとも1つのバージョンでそれをトリガーすることができました。
これにより、診断が改善されます。次のプログラムは、影響を受けるライブラリで15分未満でクラッシュします(以前にかかった1週間よりも優れています)。
// Compile with: gcc test.c -lX11 && time ./a.out
#include <X11/Xlib.h>
void main(void) {
Display *d = XOpenDisplay(NULL);
if (d)
for(;;)
XNoOp(d);
}
最後に、64ビットシステムでコンパイルおよび実行された上記のプログラムは正常に動作し、古い32ビットシステムでコンパイルおよび実行も正常に動作しますが、32ビットバージョンを64ビットシステムに転送すると、数分後にクラッシュします。
私はちょうど同じように動作し、まったく同じエラーメッセージを持つプログラムを持っていました。カウンターエラーは、クラッシュする前に2 ^ 32イベントを処理すると予想されます。
プログラムは、ワーカースレッドがXスレッドへの個別のX接続を持ち、メッセージをXスレッドに送信してウィンドウを更新できるように構成されています。
最後に、問題を追跡して、再描画するためにウィンドウにイベントを送信する関数が、ミューテックスなしで複数のスレッドによって呼び出され、同じX接続へのXがリエントラントではないため、クラッシュしましたこの正確なエラーで。関数にミューテックスを入れれば問題ありません。