Завинуть в функции poll возможно?

4. Криворукий прогер

Намек не в мою сторону. Я понятия не имею что там написали в kwin->mesa->xorg->?? но очень хочу понять кто козел и как лечить.

> подвисает в функции poll

что значит «подвисает» ?

Присоединяюсь к вопросу idle.

Это значит что мышка по экрану бегать умеет, сам kwin нахрен висит - ни события мыши/клавиатуры не воспринимает ничего не делает. Пдключаем GDB и вэктрэйсом находим что сие процесс сидит в ожидании завершения poll из libc. В этот самый poll он попал через OpenGL вызов. Вот и вопрос - можно так специально вызвать poll что бы в нем висеть или нет? Ответ знаю что можно (-1) на конце передать и все. А сам poll при корректном вызове может зависнуть или нет? Куда багрепорты слать и что с этой херней делать ума пока не приложу.

Да кедовский код вызывает glClear( GL_COLOR_BUFFER_BIT ); и усе:
#0 0x00007f52edf706b3 in poll () from /lib64/libc.so.6
#1 0x00007f52e8196c2a in _xcb_conn_wait (c=0x658500, cond=<value optimized out>, vector=0x0, count=0x0) at xcb_conn.c:313
#2 0x00007f52e81982df in xcb_wait_for_reply (c=0x658500, request=58128, e=0x7fff9cc4c3e8) at xcb_in.c:378
#3 0x00007f52f04ab2bd in _XReply (dpy=0x653f50, rep=0x7fff9cc4c440, extra=0, discard=0) at xcb_io.c:533
#4 0x00007f52ef7f5072 in DRI2GetBuffersWithFormat (dpy=0x653f50, drawable=31457313, width=0x7b0f14, height=0x7b0f18, attachments=0x7fff9cc4c540,
count=<value optimized out>, outCount=0x7fff9cc4c57c) at dri2.c:454
#5 0x00007f52ef7f2f09 in dri2GetBuffersWithFormat (driDrawable=<value optimized out>, width=0x7b0f14, height=0x7b0f18, attachments=<value optimized out>,
count=<value optimized out>, out_count=0x7fff9cc4c57c, loaderPrivate=0x7bf280) at dri2_glx.c:582
#6 0x00007f52dd1b8221 in intel_update_renderbuffers (context=<value optimized out>, drawable=0x7b0ee0) at intel_context.c:290
#7 0x00007f52dd1b8845 in intel_prepare_render (intel=<value optimized out>) at intel_context.c:438
#8 0x00007f52dd1b76a7 in intelClear (ctx=0x7bf3a0, mask=2) at intel_clear.c:95
#9 0x00007f52f49b8f25 in KWin::SceneOpenGL::paintBackground (this=<value optimized out>, region=<value optimized out>)
at /home/misha/KDE/4.5/src/kdebase/workspace/kwin/scene_opengl.cpp:892 (здеся вызвали glClear( GL_COLOR_BUFFER_BIT ) )

Так я и не понял, идет речь о нормальном ожидании (состояние S) или зависании (D).

Вот и вопрос - можно так специально вызвать poll что бы в нем висеть или нет? Ответ знаю что можно (-1) на конце передать и все.

Теперь и вопрос непонятен.

А сам poll при корректном вызове может зависнуть или нет?

Если что, -1 - это корректное значение.

> #1 0x00007f52e8196c2a in _xcb_conn_wait (c=0x658500, cond=<value optimized out>, vector=0x0, count=0x0) at xcb_conn.c:313

У X-сервера проблема, похоже.

В этом и фича что вроде как S и из него этот процесс не выходит :(

Теперь и вопрос непонятен

Если я передаю timeout >= 0 poll может попасть в бесконечное ожидание или нет?

> Если я передаю timeout >= 0 poll может попасть в бесконечное ожидание или нет?

В бесконечное - нет.

Как говориться опаньки: xcb_conn.c:313:
ret = poll(&fd, 1, -1);

Вопрос - когда сия штука может совсем зависнуть...?

> Пдключаем GDB и вэктрэйсом находим что сие процесс сидит

в ожидании завершения poll

это уже говорит о том, что задача, по крайней мере,
не «висит» в D state (uninterruptible). в противном
случае gdb не смог бы показать trace.

если timeout > 0 poll() должен завершиться, смотрите
strace'ом так ли это.

> ret = poll(&fd, 1, -1);

что-то я запутался ;)

Вопрос - когда сия штука может совсем зависнуть...?

всегда? timeout < 0 => ждать бесконечно.

Это я типа тоже знаю, но раз авторы кода такое пишут - они не козлы и обячно этот код работает тока иногда висит и ждет не понятно чего. Иными словами запрашиваемое событие должно произойти но не происходит.

Ядро 2.6.34 - говно! На 2.6.36-rc7 все летает... пока.

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

зы война программисты графики vs ноутбуки intel уже унесла не одно поколение первых так что лепите workarounds - пользователи вряд ли будут случайно переставлять ядра пока не заработает.

Чето как-то сложно... У меня изредка такое случается, помогает ALT+CTRL+F1 , ALT+F7 :)