_XReply () завершает приложение с _XIOError ()

Вероятно, это известная проблема в libX11 в отношении обработки номеров запросов, используемых для xcb_wait_for_reply.

В некоторый момент после того, как был введен код libxcb v1.5 для использования 64-битных порядковых номеров внутри, и была добавлена логика для расширения порядковых номеров при входе в эти общедоступные API, которые по-прежнему принимают 32-битные порядковые номера.

Вот цитата из представленного отчета об ошибке libxcb (удалены фактические сообщения электронной почты):

У нас есть приложение, которое делает много XDrawString и XDrawLine. Через несколько часов приложение выходит из XIOError.

XIOError вызывается в libX11 в файле xcb_io.c, function _XReply. Он не получил ответа от xcb_wait_for_reply.

libxcb 1.5 отлично, libxcb 1.8.1 - нет. Bisecting libxcb указывает на эту фиксацию:

commit ed37b087519ecb9e74412e4df8f8a217ab6d12a9 Автор: Jamey Sharp Дата: Сб Октябрь 9 17:13:45 2010 -0700

xcb_in: Use 64-bit sequence numbers internally everywhere.

Widen sequence numbers on entry to those public APIs that still take
32-bit sequence numbers.

Signed-off-by: Jamey Sharp <[email protected]>

Возврат к вершине 1.8.1 помогает.

Добавление трассировок в libxcb Я обнаружил, что последние номера запросов, используемые для xcb_wait_for_reply, следующие: 4294900463 и 4294965487 (два вызова в цикле while функции _XReply), через полсекунды: 63215 (тогда вызывается XIOError). Widen_request также 63215, я бы ожидал 63215 + 2 ^ 32. Поэтому кажется, что запрос неправильно расширился.

Компонента выше также изменила сравнение в poll_for_reply с XCB_SEQUENCE_COMPARE_32 на XCB_SEQUENCE_COMPARE. Возможно, расширение никогда не срабатывало правильно, но его никогда не наблюдали, потому что сравнивались только более низкие 32 бита.

Воспроизведение проблемы

Здесь исходный фрагмент кода из представленного отчета об ошибке, который использовался для воспроизведения проблемы:

  for(;;) {
    XDrawLine(dpy, w, gc, 10, 60, 180, 20);
    XFlush(dpy);
  }

и, по-видимому, проблема может быть воспроизведена с еще более простым кодом:

 for(;;) {
    XNoOp(dpy);
  }

Согласно представленному отчету об ошибке libxcb, эти условия необходимы для воспроизведения (при условии, что код воспроизведения находится в xdraw.c):

• libxcb> = 1.8 (т.е. включает commit ed37b08)
• скомпилировано с 32 бит: gcc -m32 -lX11 -o xdraw xdraw.c
• счетчик последовательности обертывается.

Предлагаемый патч

Предлагаемый патч, который может быть применен поверх libxcb 1.8.1, таков:

diff --git a/src/xcb_io.c b/src/xcb_io.c
index 300ef57..8616dce 100644
--- a/src/xcb_io.c
+++ b/src/xcb_io.c
@@ -454,7 +454,7 @@ void _XSend(Display *dpy, const char *data, long size)
        static const xReq dummy_request;
        static char const pad[3];
        struct iovec vec[3];
-       uint64_t requests;
+       unsigned long requests;
        _XExtension *ext;
        xcb_connection_t *c = dpy->xcb->connection;
        if(dpy->flags & XlibDisplayIOError)
@@ -470,7 +470,7 @@ void _XSend(Display *dpy, const char *data, long size)
        if(dpy->xcb->event_owner != XlibOwnsEventQueue || dpy->async_handlers)
        {
                uint64_t sequence;
-               for(sequence = dpy->xcb->last_flushed + 1; sequence <= dpy->request; ++sequence)
+               for(sequence = dpy->xcb->last_flushed + 1; (unsigned long) sequence <= dpy->request; ++sequence)
                        append_pending_request(dpy, sequence);
        }
        requests = dpy->request - dpy->xcb->last_flushed;

Подробное техническое объяснение

Здесь вы найдете подробное техническое объяснение Jonas Petersen (также включенное в вышеупомянутый отчет об ошибке):

Здравствуй,

Здесь два патча. Первый исправляет 32-битную ошибку обхода последовательности. Второй патч добавляет комментарий к другому соответствующему утверждению.

Патчи содержат некоторые детали. Вот целая история для тех, кто может быть заинтересован:

Xlib (libx11) приведет к сбою приложения с "Fatal IO error 11 (ресурс временно недоступен)" после 4 294 967 296 запросов к серверу. То есть, когда внутренняя 32-битная последовательность Xlib завершается.

Большинство приложений, вероятно, вряд ли достигнут этого числа, но если они это сделают, у них будет шанс умереть таинственной смертью. Например, приложение, над которым я работаю, всегда крутилось примерно через 20 часов, когда я начал выполнять стресс-тестирование. Он интенсивно рисует через Xlib, используя gktmm2, pixmaps и gc, со скоростью 40 кадров в секунду в полном разрешении hd (на Ubuntu). Некоторая оптимизация действительно увеличила изящество до 35 часов, но она все равно потерпит крах.

Затем последовали некоторые разочаровывающие недели рытья и отладки, чтобы понять, что это не в моем приложении, ни в gtkmm, gtk или glib, а в том, что это небольшая ошибка в Xlib, которая существует с 2006-10-06, по-видимому.

Потребовалось некоторое время, чтобы выяснить, что число 0x100000000 (2 ^ 32) имеет некоторую актуальность. (Много позже), оказалось, что он может быть воспроизведен только с помощью Xlib, используя этот код, например:

while (1) {XDrawPoint (display, drawable, gc, x, y); XFlush(display); XFlush (дисплей); } }

Это может занять один или два часа, но когда он достигнет 4294 миллиона, он взорвется в "Fatal IO error 11".

То, что я тогда узнал, состоит в том, что, хотя Xlib использует внутренние 32-битные порядковые номера, они получают (умно) расширенные до 64 бит в процессе, так что 32-битная последовательность может обернуться без какого-либо нарушения расширенной 64-битной последовательности. Очевидно, что с этим что-то не так.

Ошибка Fatal IO выдается в _XReply(), когда он не получает ответа там, где он должен быть указан, но причина ранее в _XSend() в момент, когда 32-разрядный порядковый номер Xlib завершается.

Проблема в том, что когда он обертывается до 0, значение "last_flushed" будет по-прежнему находиться на верхней границе (например, 0xffffffff). В _XSend() (xcb_io.c) есть два местоположения, которые терпят неудачу в этом состоянии, потому что они все время полагаются на последовательные значения, первое место:

request = dpy-> request - dpy-> xcb-> last_flushed;

В случае запроса = 0x0 и last_flushed = 0xffffffff он будет присваивать 0xffffffff00000001 "запросам", а затем XCB в виде количества (количества) запросов. Это главный убийца.

Второе местоположение:

для (sequence = dpy-> xcb-> last_flushed + 1; sequence <= dpy-> request;\++sequence)

В случае запроса = 0x0 (меньше, чем last_flushed) нет возможности войти в цикл заново, и в результате некоторые запросы игнорируются.

Решение состоит в том, чтобы "развернуть" dpy-> запрос в этих двух местах и таким образом сохранить последовательность, связанную с last_flushed.

uint64_t unwrapped_request = ((uint64_t) (dpy-> запрос <\ dpy-> xcb-> last_flushed) << 32) + dpy-> запрос;

Он создает временный 64-битный номер запроса, который имеет бит 8, если "запрос" меньше, чем "last_flushed". Затем он используется в двух местах вместо запроса dpy->.

Я не уверен, может ли быть более эффективным использовать этот оператор inplace вместо использования переменной.

Есть еще одна строка в require_socket(), которая меня сначала беспокоила:

dpy-> xcb-> last_flushed = dpy-> request = sent;

Это 64-битное, 32-битное, 64-битное назначение. Он будет усекать "отправлено" на 32-битный, когда он будет "запрашивать", а затем также назначит усеченное значение (64-разрядному) "last_flushed". Но это кажется интуитивным. Я добавил примечание, объясняющее, что для следующей неудовлетворительной проблемы с отладкой души... :-)

• Jonas

Jonas Petersen (2): xcb_io: Fix Xlib Оболочка 32-разрядных запросов xcb_io: Добавить комментарий, объясняющий двойное назначение смешанного типа

src/xcb_io.c | 14 +++++++++++ --- 1 файл изменен, 11 вставок (+), 3 удаления (-)

- 1.7.10.4

Удачи!