eglSwapBuffers никогда не возвращается - PullRequest
0 голосов
/ 21 октября 2018

Я разрабатываю простую игру на Raspberry Pi 3. В качестве операционной системы я использую официальную Raspbian Stretch Lite.Игра запускается без X-сервера и разработана на C ++ с использованием библиотеки SFML PI .

Проблема в том, что игра время от времени зависает.Это может произойти через несколько секунд или несколько часов запуска игры, но рано или поздно это всегда происходит.Стек стоп-кадра freeze указывает, что eglSwapBuffers никогда не возвращается.Более того, убить игру и запустить ее снова не поможет - она ​​зависает при запуске на eglCreatePbufferSurface звонке.После перезагрузки начинается снова.В чем может быть причина такой заморозки?Можно ли как-то это отладить?Я очень боюсь, что это может быть вызвано ошибкой в ​​реализации SFML PI или EGL.

Stacktrace основного потока во время остановки основного потока:

Thread 1 (Thread 0x76293000 (LWP 802)):
#0  0x76f3c014 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=1, 
    futex_word=0x76459b84 <pool_mem+1444>) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  do_futex_wait (sem=sem@entry=0x76459b84 <pool_mem+1444>, abstime=0x0) at sem_waitcommon.c:115
#2  0x76f3c158 in __new_sem_wait_slow (sem=0x76459b84 <pool_mem+1444>, abstime=0x0) at sem_waitcommon.c:282
#3  0x76804548 in eglSwapBuffers () from /opt/vc/lib/libbrcmEGL.so
#4  0x76ed14b8 in sf::Window::display() () from /usr/lib/libsfml-window.so.2.4
#5  0x000a8038 in Game::run() ()
#6  0x0013d9ec in main ()

Stacktrace freeze во время запуска послеубиваю игру:

Thread 1 (Thread 0x76223000 (LWP 1001)):
#0  0x76ecc014 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=1, 
---Type <return> to continue, or q <return> to quit---
    futex_word=0x767c1a58 <khrn_queue+76>) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  do_futex_wait (sem=sem@entry=0x767c1a58 <khrn_queue+76>, abstime=0x0) at sem_waitcommon.c:115
#2  0x76ecc158 in __new_sem_wait_slow (sem=0x767c1a58 <khrn_queue+76>, abstime=0x0) at sem_waitcommon.c:282
#3  0x763eeb60 in vchiu_queue_pop () from /opt/vc/lib/libvchiq_arm.so
#4  0x7679b014 in rpc_recv () from /opt/vc/lib/libbrcmEGL.so
#5  0x76795b54 in egl_surface_create () from /opt/vc/lib/libbrcmEGL.so
#6  0x767923b8 in eglCreatePbufferSurface () from /opt/vc/lib/libbrcmEGL.so
#7  0x76e635f4 in sf::priv::EglContext::EglContext(sf::priv::EglContext*) () from /usr/lib/libsfml-window.so.2.4
#8  0x76e5f2b0 in sf::priv::GlContext::initResource() () from /usr/lib/libsfml-window.so.2.4
#9  0x76e5f95c in sf::GlResource::GlResource() () from /usr/lib/libsfml-window.so.2.4
#10 0x76e60f54 in sf::Window::Window() () from /usr/lib/libsfml-window.so.2.4
#11 0x76ea2d7c in sf::RenderWindow::RenderWindow(sf::VideoMode, sf::String const&, unsigned int, sf::ContextSettings const&) () from /usr/lib/libsfml-graphics.so.2.4
#12 0x000a8642 in Game::Game() ()
#13 0x0013d9e6 in main ()

1 Ответ

0 голосов
/ 26 марта 2019

Отказ от ответственности : Это не решение, а какой-то шаг, который может помочь вам определить или решить проблему.

Что еще больше убивает игру и запускает ее снова?t help

Это означает, что вы, скорее всего, столкнулись с проблемой уровня драйвера.Любая проблема приложения будет исправлена ​​путем ее перезапуска (при условии, что ваше приложение работает так же).И тот факт, что он зависает, плюс ссылки на sem_waitcommon и просмотр стека, конечно, означает, что вы попали в тупик, исходящий из libbrcmEGL.so, видеодрайвера.Плохая новость заключается в том, что ошибки в видеодрайвере случаются, их может быть довольно сложно решить, и, поскольку драйвер является закрытым исходным кодом, вы не сможете исправить его самостоятельно или исправить его сообществом ...

Мне не удалось найти проблему, точно совпадающую с вашей, которая может указывать на ошибку, которая еще не идентифицирована, из-за конкретной комбинации программного обеспечения и используемой вами версии:

  • Ваш текущийдистрибутив: kernel, glibc, версия прошивки cbrm
  • Ваш движок: SFML, SFML PI
  • И тот факт, что вы используете EGL, а не X11

Ниже приведенынекоторые шаги, начиная с самого простого

Peek at dmesg

Это очень простой первый шаг, который может дать ценную информацию.Когда проблема возникает, после первого и второго зависания, посмотрите, появляется ли что-нибудь.Здесь будет поднята любая важная проблема, и вы сможете пролить свет на вашу проблему.

Сообщить об ошибке

Первый шаг, вероятно, - сообщить о проблеме в raspberrypi / linux , с MVE.Это может занять некоторое время, но, возможно, вам лучше всего решить эту проблему, поскольку встроенное программное обеспечение графического процессора (Videocore IV, как libbrcmEGL.so) является закрытым.

SFML / SFML PI

Ваша ошибка, вероятно, связана с определенным набором операций над драйвером, который в итоге вызывает ошибку, которую вы видите.Я бы порекомендовал сократить ваш код до минимума, чтобы попытаться определить причину проблемы.К сожалению, тот факт, что это происходит случайно, не поможет.Даже если это, вероятно, не решит основную проблему, вы можете обойти ее.

Попробуйте другую версию SFML

Либо обновите, либо понизьте версию SFML и SFML PI.Используем.Опять же, это не решит проблему с ядром, но может ее избежать.

Прошивка старого дистрибутива Raspbian

Если это регрессия в видеодрайвере, вы можете исправить этопрошивая старую версию дистрибутива, от здесь

Чтобы минимизировать усилия, вы можете попробовать вручную извлечь другую версию libEGL* и libbrcmEGL.so из raspberry /прошивка , но вы можете столкнуться с проблемами совместимости с их зависимостями.

Переключиться на X11

Я знаю ... EGL определенно даст вам лучшую производительность, и вы, вероятно, ненужен этот рабочий стол и состав.Но, учитывая более широкое сообщество и использование, скорее всего, вы столкнетесь с гораздо меньшими проблемами.И поскольку он использует libbrcmGLESv2.so, вам гарантированно, что тот же (возможно, ошибочный) код не будет выполнен.

...