Program will not terminate properly

[AJRed]

EDIT: Just noticed that it oddly will only halt on a blue (even) final frame. I don't think that should be the case here, since the frame I halt on should be arbitrary. but it seems to only halt on even numbered frames. I'm no expert but I'm not exactly new either, this should be trivial but apparently its not. I feel like a moron for having to ask such a simple question.

I have been having an odd issue that seems to occur when terminating my program. The display will not close, and it will remain open in the background. I need to use "kill -KILL {PID}" to actually terminate the program and get my terminal back, "kill -TERM {PID}" does not end the process. This appears to be a reference from the non-ce issues tracker to a similar problem. https://github.com/pygame/pygame/issues/4345 I have tried using both versions of pygame, and both exhibit the same issues. I use venv to create a virtual environment and then install pygame to that environment using pip. Every project gets its own environment, pygame is the only package installed in the environment besides default packages, and I don't have my environments access system packages. So it should be a very clean environment with little pollution.

import pygame

pygame.init()
screen = pygame.display.set_mode((200, 200))
screen.fill(pygame.Color(0, 0, 0))
count = 0
running = True
while running:
    if not count % 2:
        screen.fill(pygame.Color(255, 0, 0))
    else:
        screen.fill(pygame.Color(0, 0, 255))
    count += 1
    pygame.display.flip()
    for e in pygame.event.get():
        if e.type == pygame.QUIT:
            print(e.type)
            print('QUITTING')
            running = False
pygame.quit()

This example should quit when you send a pygame.QUIT event. But when I do that it halts the loop properly and seems to exit, or at least halt, pygame (There's no more screen updates or events) but the window remains open and displaying the last frame it should have been. I know it's way more than I need to test this situation but I wanted to get an idea what was going on so I had some other things happening hoping to see a clue. No such luck however.

[ankith26]

Cannot reproduce this issue, I'm on a standard Ubuntu 24.10 install. Could you provide more details about your environment, this must be an issue specific to something about your setup.

You can start by pasting the output of pygame.print_debug_info(). For me, I have

>>> pygame.print_debug_info()
Platform:       Linux-6.11.0-9-generic-x86_64-with-glibc2.40
System:         Linux
System Version:     #9-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct 14 13:19:59 UTC 2024
Processor:      x86_64  SSE2: Yes   AVX2: Yes   NEON: No
Architecture:       Bits: 64bit Linkage: ELF

Python:         CPython 3.12.7 (main, Oct  3 2024, 15:15:22) [GCC 14.2.0]
pygame version:     2.5.3.dev1
SDL versions:       Linked: 2.31.0  Compiled: 2.31.0
SDL Mixer versions: Linked: 2.8.0   Compiled: 2.8.0
SDL Font versions:  Linked: 2.22.0  Compiled: 2.22.0
SDL Image versions: Linked: 2.8.2   Compiled: 2.8.2
Freetype versions:  Linked: 2.13.3  Compiled: 2.13.3

Display Driver:     x11 ( xwayland == True )
Mixer Driver:       alsa

[oddbookworm]

Cannot reproduce this issue, I'm on a standard Ubuntu 24.10 install. Could you provide more details about your environment, this must be an issue specific to something about your setup.

You can start by pasting the output of pygame.print_debug_info(). For me, I have

>>> pygame.print_debug_info()
Platform:     Linux-6.11.0-9-generic-x86_64-with-glibc2.40
System:           Linux
System Version:       #9-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct 14 13:19:59 UTC 2024
Processor:        x86_64  SSE2: Yes   AVX2: Yes   NEON: No
Architecture:     Bits: 64bit Linkage: ELF

Python:           CPython 3.12.7 (main, Oct  3 2024, 15:15:22) [GCC 14.2.0]
pygame version:       2.5.3.dev1
SDL versions:     Linked: 2.31.0  Compiled: 2.31.0
SDL Mixer versions:   Linked: 2.8.0   Compiled: 2.8.0
SDL Font versions:    Linked: 2.22.0  Compiled: 2.22.0
SDL Image versions:   Linked: 2.8.2   Compiled: 2.8.2
Freetype versions:    Linked: 2.13.3  Compiled: 2.13.3

Display Driver:       x11 ( xwayland == True )
Mixer Driver:     alsa

Also, make sure you call pygame.init() before this to get all the infos

[AJRed]

Thank you for your response

Platform:       Linux-6.10.13-3-MANJARO-x86_64-with-glibc2.40
System:         Linux
System Version:     #1 SMP PREEMPT_DYNAMIC Tue Oct  8 03:24:49 UTC 2024
Processor:          SSE2: Yes   AVX2: No    NEON: No
Architecture:       Bits: 64bit Linkage: ELF

Python:         CPython 3.12.6 (main, Sep  8 2024, 13:18:56) [GCC 14.2.1 20240805]
pygame version:     2.5.2
SDL versions:       Linked: 2.30.8  Compiled: 2.30.8
SDL Mixer versions: Linked: 2.8.0   Compiled: 2.8.0
SDL Font versions:  Linked: 2.22.0  Compiled: 2.22.0
SDL Image versions: Linked: 2.8.2   Compiled: 2.8.2
Freetype versions:  Linked: 2.13.3  Compiled: 2.13.3

Display Driver:     x11 ( xwayland == False )
Mixer Driver:       pulseaudio

Something I notice is I was expecting pipewire to be the mixer driver. Not sure if that could be related.

[ankith26]

I see you are running on x11 directly (and not xwayland). What DE/WM are you using? Might be relevant to the issue

[AJRed]

I am running i3 as wm, and no DE. I just installed and configured everything myself. I haven't changed much about my setup in almost a year, save the change from pure pulse to pipewire. Is there any way to make pygame more verbose?

[AJRed]

Now that I'm home, I ran the code on my almost identically configured desktop and it works just fine, so I think this might just be one of those annoying computer problems you don't get to know about. Without any error messages to investigate I'm at a bit of a loss. I appreciate the help nonetheless.

[AJRed]

Update: It was pygame.mixer not playing nice with my probably misconfigured pipewire setup. If i call other modules' init methods and pygame.quit() everything is fine, but as soon as I quit after calling mixer.init() it hangs. Glad I figured that out it was making me angry. It was a thread from 2013 that tipped me off. Thanks for the help guys I appreciate it.

[ankith26]

Glad you figured it out.

BTW, incase this is helpful, SDL2 defaults to using pulseaudio even when pipewire is available. To force a different audiodriver you can set the SDL_AUDIODRIVER environment variable, like SDL_AUDIODRIVER=pipewire for pipewire and SDL_AUDIODRIVER=alsa for alsa.

[AJRed]

Glad you figured it out.

BTW, incase this is helpful, SDL2 defaults to using pulseaudio even when pipewire is available. To force a different audiodriver you can set the SDL_AUDIODRIVER environment variable, like SDL_AUDIODRIVER=pipewire for pipewire and SDL_AUDIODRIVER=alsa for alsa.

Thank you. export SDL_AUDIODRIVER=pipewire; python main.py works seamlessly as expected.