Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segfault when _sdl2.Renderer gets garbage collected after window has been destroyed #4210

Open
Yarn opened this issue Apr 16, 2024 · 0 comments
Labels
bug needs-tests Unit tests need writing

Comments

@Yarn
Copy link

Yarn commented Apr 16, 2024

Environment:

You can get some of this info from the text that pops up in the console when you run a pygame program.

  • Operating system : Linux(Arch) in LXD container on Linux(Arch) host
  • Python version : 3.11.8
  • SDL version : 2.28.2
  • PyGame version : 2.5.2

Current behavior:

Program segfaults.

Expected behavior:

Program exits without segfaulting.

Steps to reproduce:

Run test code. Does not segfault on all systems.

Test code

import pygame
from pygame._sdl2 import Window, Texture, Renderer

def test():
    pygame.display.init()
    
    window = Window('-', size = (1280, 720))
    render = Renderer(window)
    
    window.show()
    
    # del render
    window.destroy()
    print('aa')

def main():
    print('a')
    test()
    print('b')

main()

Uncommenting del render results in the program exiting cleanly.

Stack trace/error output/other error logs

pygame 2.5.2 (SDL 2.28.2, Python 3.11.8)
Hello from the pygame community. https://www.pygame.org/contribute.html
a
aa
fish: Job 1, '[...]' terminated by signal SIGSEGV (Address boundary error)

Another user tested on Ubuntu 22.04.4 LTS ("jammy") with the system python install and the latest pygame installed from pip in a venv. They did not experience a segfault but got the following output from valgrind. It appears Renderer was still trying to access the Window after it was destroyed even though they did not experience a segfault.

==24681== Invalid read of size 8
==24681==    at 0x58AE311: ??? (in /…/py/lib/python3.10/site-packages/pygame.libs/libSDL2-2-a598e802.0.so.0.2800.2)
==24681==    by 0x582D4DB: ??? (in /…/py/lib/python3.10/site-packages/pygame.libs/libSDL2-2-a598e802.0.so.0.2800.2)
==24681==    by 0x75AB666: __pyx_tp_dealloc_6pygame_5_sdl2_5video_Renderer (in /…/py/lib/python3.10/site-packages/pygame/_sdl2/video.cpython-310-x86_64-linux-gnu.so)
==24681==    by 0x254FF0: _PyEval_EvalFrameDefault (in /usr/bin/python3.10)
==24681==    by 0x2629FB: _PyFunction_Vectorcall (in /usr/bin/python3.10)
==24681==    by 0x24B26C: _PyEval_EvalFrameDefault (in /usr/bin/python3.10)
==24681==    by 0x2479C5: ??? (in /usr/bin/python3.10)
==24681==    by 0x33D255: PyEval_EvalCode (in /usr/bin/python3.10)
==24681==    by 0x368107: ??? (in /usr/bin/python3.10)
==24681==    by 0x3619CA: ??? (in /usr/bin/python3.10)
==24681==    by 0x367E54: ??? (in /usr/bin/python3.10)
==24681==    by 0x367337: _PyRun_SimpleFileObject (in /usr/bin/python3.10)
==24681==  Address 0xb20e500 is 0 bytes inside a block of size 240 free'd
==24681==    at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==24681==    by 0x586008E: ??? (in /…/py/lib/python3.10/site-packages/pygame.libs/libSDL2-2-a598e802.0.so.0.2800.2)
==24681==    by 0x75AC6CB: __pyx_pw_6pygame_5_sdl2_5video_6Window_11destroy (in /…/py/lib/python3.10/site-packages/pygame/_sdl2/video.cpython-310-x86_64-linux-gnu.so)
==24681==    by 0x24B45B: _PyEval_EvalFrameDefault (in /usr/bin/python3.10)
==24681==    by 0x2629FB: _PyFunction_Vectorcall (in /usr/bin/python3.10)
==24681==    by 0x24B26C: _PyEval_EvalFrameDefault (in /usr/bin/python3.10)
==24681==    by 0x2629FB: _PyFunction_Vectorcall (in /usr/bin/python3.10)
==24681==    by 0x24B26C: _PyEval_EvalFrameDefault (in /usr/bin/python3.10)
==24681==    by 0x2479C5: ??? (in /usr/bin/python3.10)
==24681==    by 0x33D255: PyEval_EvalCode (in /usr/bin/python3.10)
==24681==    by 0x368107: ??? (in /usr/bin/python3.10)
==24681==    by 0x3619CA: ??? (in /usr/bin/python3.10)
@Yarn Yarn added the bug label Apr 16, 2024
@illume illume added the needs-tests Unit tests need writing label Apr 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug needs-tests Unit tests need writing
Projects
None yet
Development

No branches or pull requests

2 participants