c++ - eglSwapBuffers 永远不会返回

Question

我正在 Raspberry Pi 3 上开发一个简单的游戏。作为操作系统，我使用官方的 Raspbian Stretch Lite。该游戏在没有 X 服务器的情况下运行，并使用 SFML PI 在 C++ 中开发。图书馆。

问题是游戏有时会卡顿。它可能会在运行游戏几秒钟或几小时后发生，但迟早总会发生。 freeze 的堆栈跟踪表明 eglSwapBuffers 永远不会返回。更重要的是终止游戏并再次运行它没有帮助 - 它在 eglCreatePbufferSurface 调用启动期间卡住。它在重新启动后再次启动。这种卡住的原因是什么？我可以以某种方式调试它吗？我很担心它可能是由 SFML PI 或 EGL 实现中的错误引起的。

主线程卡住期间主线程的堆栈跟踪:

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 ()

杀死游戏后启动过程中卡住的堆栈跟踪:

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 ()

Answer 1

免责声明:这不是解决方案，而是可以帮助您识别或解决问题的一些步骤。

What's more killing the game and running it again doesn't help

这意味着您很可能面临驱动程序级别的问题。任何应用程序问题都可以通过重新启动来解决(假设您的应用程序运行相同)。它卡住的事实，加上对 sem_waitcommon 的引用和查看堆栈，当然意味着您遇到了死锁，源自 libbrcmEGL.so，视频驱动程序。坏消息是，视频驱动程序中会出现错误，解决起来可能相当复杂，而且由于驱动程序是封闭源代码，您无法自行修复它，也无法让社区修复它...

由于您使用的软件和版本的特定组合，我无法找到与您的问题完全匹配的问题，这可能指向一个尚未识别的错误:

• 您当前的发行版:内核、glibc、cbrm 固件版本
• 您的引擎:SFML、SFML PI
• 事实上您使用的是 EGL 而不是 X11

下面是一些步骤，从最简单的开始

查看dmesg

这是一个非常简单的第一步，可能会产生有值(value)的信息。出现问题时，在第一次和第二次卡住后，查看是否有任何显示。任何重要的问题都会在那里提出，并照亮您的问题。

报告错误

第一步可能是在raspberrypi/linux中报告问题, 有一个 MVE。这可能需要一些时间，但也许是解决该问题的最佳选择，因为 GPU 的固件(Videocore IV，如 libbrcmEGL.so)是封闭源代码。

SFML/SFML PI

您的错误可能是由于驱动程序上的一组特定操作最终触发了您所看到的错误。我建议将您的代码减少到最少，以尝试确定是什么触发了问题。不幸的是，它随机发生的事实无济于事。即使这可能无法解决核心问题，您也可以绕过它。

尝试不同版本的 SFML

升级或降级您正在使用的 SFML 和 SFML PI 的版本。同样，这不会解决核心问题，但可能会避免它。

刷入旧的 Raspbian 发行版

如果这是视频驱动程序中的回归，您可以通过刷新旧版本的分发来修复它，来自 here

为了尽量减少工作量，您可以尝试从 raspberry/firmware 手动 check out 不同版本的 libEGL* 和 libbrcmEGL.so ，但您可能会遇到与它们的依赖项的兼容性问题。

切换到 X11

我知道...EGL 肯定会给您带来更好的性能，您可能不需要那个桌面和组合。但是考虑到更大的社区和使用，您遇到的麻烦可能会少得多。因为它使用 libbrcmGLESv2.so，所以可以保证不会执行相同(可能有问题)的代码。