[Scummvm-tracker] [ScummVM :: Bugs] #13998: GRAPHICS: OpenGL::Framebuffer::deactivate crash with gui_return_to_launcher_at_exit

ScummVM :: Bugs trac at scummvm.org
Sun Jan 1 13:33:51 UTC 2023


#13998: GRAPHICS: OpenGL::Framebuffer::deactivate crash with
gui_return_to_launcher_at_exit
--------------------------+----------------------
Reporter:  dwatteau       |      Owner:  (none)
    Type:  defect         |     Status:  new
Priority:  normal         |  Component:  Graphics
 Version:                 |   Keywords:
    Game:  Grim Fandango  |
--------------------------+----------------------
 This is with ScummVM 2.7.0git-c93d460ee24 on OSX 10.4/10.5 PPC.
 Investigating a bit, I don't think this is port-related or game-related,
 and that the issue is somewhere in the graphics backend, but I may be
 wrong, so adjust this if necessary.

 On this setup, if I:

 1. Enable `gui_return_to_launcher_at_exit`
 2. Start the demo of Grim Fandango
 3. Exit it (once the first scene is fully loaded) in order to go back to
 the launcher

 then ScummVM always crashes with the following backtrace:

 {{{
 WARNING: Libretro is not supported!
 Program received signal EXC_BAD_ACCESS, Could not access memory.
 Reason: KERN_PROTECTION_FAILURE at address: 0x0000000c
 0x0026a6c8 in OpenGL::Framebuffer::deactivate (this=<incomplete type>) at
 ./backends/graphics/opengl/framebuffer.h:159
 159     class Backbuffer : public Framebuffer {

 (gdb) bt
 #0  0x0026a6c8 in OpenGL::Framebuffer::deactivate (this=<incomplete type>)
 at ./backends/graphics/opengl/framebuffer.h:159
 #1  0x0027aa00 in OpenGL::Pipeline::deactivateInternal (this=0x8a13fa0) at
 ./backends/graphics/opengl/pipelines/pipeline.h:153
 #2  0x0028b0f4 in OpenGL::ShaderPipeline::deactivateInternal
 (this=0x8a13fa0) at ./common/hashmap.h:92
 #3  0x0027a9a4 in OpenGL::Pipeline::deactivate (this=0x8a13fa0) at
 ./backends/graphics/opengl/pipelines/pipeline.h:153
 #4  0x0027a8a0 in OpenGL::Pipeline::activate (this=0x8a4a540) at
 ./backends/graphics/opengl/pipelines/pipeline.h:153
 #5  0x0026e354 in OpenGL::OpenGLGraphicsManager::updateScreen
 (this=0x2858400) at ./backends/graphics/opengl/framebuffer.h:159
 #6  0x002a8ac0 in OpenGLSdlGraphicsManager::updateScreen (this=0x2858400)
 at ./common/func.h:71
 #7  0x0024b1dc in ModularGraphicsBackend::updateScreen (this=0x233f018) at
 ./common/base-str.h:173
 #8  0x001b6a1c in GUI::GuiManager::screenChange (this=<incomplete type>)
 at ./common/ptr.h:299
 #9  0x001b68e0 in GUI::GuiManager::checkScreenChange (this=<incomplete
 type>) at ./common/ptr.h:299
 #10 0x001a8118 in GUI::Dialog::Dialog (this=<incomplete type>,
 name=<incomplete type>) at ./gui/dialog.h:49
 #11 0x001b948c in GUI::LauncherDialog::LauncherDialog (this=0x29e0600,
 dialogName=<incomplete type>, chooser=0xbfffcb48) at
 ./common/memorypool.h:148
 }}}

 (more GDB output attached below; note that this port has a very limited
 GDB and so its output is just a rough indication)

 With some more manual debugging, it looks like the crash appears when
 `pipeline.cpp:Pipeline::deactivateInternal()` calls
 `_activeFramebuffer->deactivate()` and then
 `framebuffer.cpp:Framebuffer::deactivate()` calls `deactivateInternal()`
 which crashes.

 This wouldn't happen with ScummVM 2.6.1 on the same setup. 2D games are
 fine, even when rendering them with OpenGL.

 `configure` enabled the following GL-related features:

 {{{
 config.h:#define USE_GLES_MODE 0
 config.h:#define USE_OPENGL
 config.h:#define USE_GLAD
 config.h:#define USE_OPENGL_GAME
 config.h:#define USE_OPENGL_SHADERS

 config.mk:USE_OPENGL = 1
 config.mk:USE_GLAD = 1
 config.mk:USE_OPENGL_GAME = 1
 config.mk:USE_OPENGL_SHADERS = 1
 }}}

 and I'm including some OpenGL debug below too.

 If I disable the `gui_return_to_launcher_at_exit` feature there, I'm not
 seeing any crash.
-- 
Ticket URL: <https://bugs.scummvm.org/ticket/13998>
ScummVM :: Bugs <https://bugs.scummvm.org>
ScummVM


More information about the Scummvm-tracker mailing list