c++ - 调试 X11 程序时如何避免 SIGPIPE(由于超时？)？

Question

有时，当我在 X11 上调试我的 Qt 程序时，我需要在程序已经创建了一个窗口(QWidget)但还没有窗口显示的点上设置一个断点.在这种情况下，当我在一段时间后从该断点恢复程序时，程序得到 SIGPIPE。当程序在显示窗口之前做了一些事情时也会发生这种情况，并且 Valgrind 将其减慢到如此低的速度以至于 X11 再次超时。至少它看起来与某种超时有关。

我已经设法制作了一个小型测试用例，无需使用调试器或 Valgrind 即可完全重现问题:

#include <QThread>
#include <QWidget>
#include <QApplication>

int main(int argc, char** argv)
{
    QApplication app(argc, argv);
    QWidget widget;
    QThread::currentThread()->sleep(60);
    widget.show();
    return app.exec();
}

当此程序获得 SIGPIPE 时，其堆栈跟踪如下所示:

Thread 1 "test" received signal SIGPIPE, Broken pipe.
0x00007ffff6385187 in __GI___libc_write (fd=6, buf=buf@entry=0x5555557be990, nbytes=nbytes@entry=80) at ../sysdeps/unix/sysv/linux/write.c:27
27      ../sysdeps/unix/sysv/linux/write.c: No such file or directory.
(gdb) bt
#0  0x00007ffff6385187 in __GI___libc_write (fd=6, buf=buf@entry=0x5555557be990, nbytes=nbytes@entry=80) at ../sysdeps/unix/sysv/linux/write.c:27
#1  0x00007fffed6e5cd8 in _IceTransSocketWrite (ciptr=0x5555557be4b0, buf=0x5555557be990 "\001\f\001", size=80) at /usr/include/X11/Xtrans/Xtranssock.c:2396
#2  0x00007fffed6ea558 in _IceWrite (iceConn=0x5555557c3d80, nbytes=<optimized out>, ptr=0x5555557be990 "\001\f\001") at ../../src/misc.c:350
#3  0x00007fffed6ea644 in IceFlush (iceConn=0x5555557c3d80) at ../../src/misc.c:78
#4  0x00007fffefa56c24 in sm_setProperty (name=0x5555557daa08 "Program", type=0x7fffefb0667a "ARRAY8", num_vals=1, vals=0x7fffffffccc0) at qxcbsessionmanager.cpp:123
#5  0x00007fffefa56ce8 in sm_setProperty (name="Program", value="/tmp/test/test") at qxcbsessionmanager.cpp:137
#6  0x00007fffefa57188 in sm_performSaveYourself (sm=0x5555557753e0) at qxcbsessionmanager.cpp:202
#7  0x00007fffefa56f93 in sm_saveYourselfCallback (smcConn=0x5555557bc9e0, clientData=0x5555557753e0, saveType=1, shutdown=0, interactStyle=0) at qxcbsessionmanager.cpp:180
#8  0x00007fffed8fdb28 in _SmcProcessMessage (iceConn=0x5555557c3d80, clientData=0x5555557bc9e0, opcode=<optimized out>, length=<optimized out>, swap=0, replyWait=<optimized out>, replyReadyRet=0x7fffffffd2d0) at ../../src/sm_process.c:241
#9  0x00007fffed6ee978 in IceProcessMessages (iceConn=0x5555557c3d80, replyWait=0x0, replyReadyRet=0x0) at ../../src/process.c:386
#10 0x00007fffefa57ae6 in QSmSocketReceiver::socketActivated (this=0x5555557be520) at qxcbsessionmanager.cpp:331
#11 0x00007fffefa58298 in QSmSocketReceiver::qt_static_metacall (_o=0x5555557be520, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0x7fffffffd4a0) at .moc/qxcbsessionmanager.moc:70
#12 0x00007ffff6f6521d in QMetaObject::activate (sender=0x5555557be450, signalOffset=3, local_signal_index=0, argv=0x7fffffffd4a0) at kernel/qobject.cpp:3795
#13 0x00007ffff6f649e6 in QMetaObject::activate (sender=0x5555557be450, m=0x7ffff733bda0 <QSocketNotifier::staticMetaObject>, local_signal_index=0, argv=0x7fffffffd4a0) at kernel/qobject.cpp:3648
#14 0x00007ffff6f72321 in QSocketNotifier::activated (this=0x5555557be450, _t1=6, _t2=...) at .moc/moc_qsocketnotifier.cpp:140
#15 0x00007ffff6f72081 in QSocketNotifier::event (this=0x5555557be450, e=0x7fffffffda20) at kernel/qsocketnotifier.cpp:266
#16 0x00007ffff74c1ce4 in QApplicationPrivate::notify_helper (this=0x5555557701d0, receiver=0x5555557be450, e=0x7fffffffda20) at kernel/qapplication.cpp:3736
#17 0x00007ffff74bf0a2 in QApplication::notify (this=0x7fffffffdc60, receiver=0x5555557be450, e=0x7fffffffda20) at kernel/qapplication.cpp:3093
#18 0x00007ffff6f1c919 in QCoreApplication::notifyInternal2 (receiver=0x5555557be450, event=0x7fffffffda20) at kernel/qcoreapplication.cpp:1060
#19 0x00007ffff6f1d316 in QCoreApplication::sendEvent (receiver=0x5555557be450, event=0x7fffffffda20) at kernel/qcoreapplication.cpp:1450
#20 0x00007ffff6fa5a27 in QEventDispatcherUNIXPrivate::activateSocketNotifiers (this=0x555555774f30) at kernel/qeventdispatcher_unix.cpp:304
#21 0x00007ffff6fa686e in QEventDispatcherUNIX::processEvents (this=0x7fffe4001460, flags=...) at kernel/qeventdispatcher_unix.cpp:509
#22 0x00007fffefa4715a in QXcbUnixEventDispatcher::processEvents (this=0x7fffe4001460, flags=...) at qxcbeventdispatcher.cpp:60
#23 0x00007ffff6f19169 in QEventLoop::processEvents (this=0x7fffffffdbd0, flags=...) at kernel/qeventloop.cpp:138
#24 0x00007ffff6f194a3 in QEventLoop::exec (this=0x7fffffffdbd0, flags=...) at kernel/qeventloop.cpp:225
#25 0x00007ffff6f1d15a in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1363
#26 0x00007ffff584f1c4 in QGuiApplication::exec () at kernel/qguiapplication.cpp:1779
#27 0x00007ffff74be931 in QApplication::exec () at kernel/qapplication.cpp:2893
#28 0x0000555555554c34 in main (argc=1, argv=0x7fffffffdda8) at test.cpp:11

如果我忽略这个信号(例如在 GDB 中说 signal 0)，那么我会得到错误

ICE default IO error handler doing an exit(), pid = 3850, errno = 32

所以简单地做类似 sigaction 的解决方法是行不通的。

我的问题是:如果这确实是一些 X11 超时，我该如何禁用或增加此超时？如果不是超时，那么它是什么以及如何避免此 SIGPIPE/ICE 错误问题？

Answer 1

看来，如果我在创建 QApplication 实例后立即调用 QApplication::processEvents()，则 SIGPIPE 不会不会发生。显然，Qt 以某种方式“确认”应用程序对 X11 的有效性以响应某些事件，然后让应用程序尽可能慢，而没有任何致命的惩罚。

编辑后的示例代码如下:

#include <QThread>
#include <QWidget>
#include <QApplication>

int main(int argc, char** argv)
{
    QApplication app(argc, argv);
    app.processEvents(); // This avoids SIGPIPE
    QWidget widget;
    QThread::currentThread()->sleep(60);
    widget.show();
    return app.exec();
}

我仍然不知道到底发生了什么，什么事件需要迅速 react ，以及超时是否可以延长，但至少上述解决方法让我可以继续调试。