This program breaks on my Linux

[bw]

Howdy,

Hoping some folks can try this out. I have no idea why it is happening.
Not even a theory. Could be anything from drivers to the Python or SDL
build. Here's the scoop...

The environment:
- i5 desktop computer (not a virtual machine)
- Ubuntu 13.04 x86_64
- Python 2.7
- pygame 1.9.1

The program blits a checkerboard background using only two images, and
pans the images diagonally back and forth forever. The clock is not
throttled.

The problem usually occurs anywhere from 3 to 120 seconds after start.
During the normal behavior, I'm getting about 320 fps with occasional
instantaneous spikes to 500+ fps. (I don't know if the spikes are
normal. They do cause visible glitches.)

During the problem behavior the fps spikes permanently to about 580 fps
and stays pegged. Who would complain about sustained 580 fps, ay? :)
Well, then when pygame quits, the program freezes and the window remains
open with the checker pattern intact. SIGTERM (15) does not kill the
program. SIGKILL (9) does.

This issue does not happen in Windows 7. And it does not happen if I
throttle the clock enough to lower the max fps.

I attached the small program. I'm curious if anyone can run it and
reproduce the problem. I plan on upgrading Ubuntu soon, when I am ready
to risk it: maybe the problem will go away. I'll post the outcome--but
I've been too busy to risk the upgrade, so don't hold yer breath. =)

Thanks.

Gumm

[Sam Bull]

Post by bw
I attached the small program. I'm curious if anyone can run it and
reproduce the problem. I plan on upgrading Ubuntu soon, when I am ready
to risk it: maybe the problem will go away. I'll post the outcome--but
I've been too busy to risk the upgrade, so don't hold yer breath. =)

No idea what the problem could be. I can't reproduce it, but also not
getting more than 130 FPS on my old laptop. I'm curious as to exactly
when it crashes though, can you add some print statements to find
exactly where it crashes?

if e.key == K_ESCAPE:
print("Before")
pygame.quit()
print("After Pygame exit")
quit()
print("Never reached")

I'd also experiment with a couple of different exit functions, to see if
that makes any difference. For example, try removing the pygame.quit()
call (Pygame will exit safely with Python anyway, so it's a redundant
call here), and using sys.exit() instead of the builtin.

[bw]

if e.key == K_ESCAPE:
print(1)
pygame.display.get_init()
print(2)
pygame.display.get_surface()
print(3)
screen.unlock()
print(4)
pygame.display.set_mode((16, 64))
print(5)
pygame.display.flip()
print(6)
pygame.quit()
print(7)
sys.exit()
print(8)

In this sequence it's understood 8 will never be reached. When the
program exits normally 7 is printed and the program terminates. When the
fps gallops away, indicating the problem has occurred, the last thing
printed is always 6 and the program hangs. In all cases the pygame
functions return, except for pygame.quit(). When trying other exit
routines in lieu of pygame.quit() the exiting statement hangs, I presume
because pygame's cleanup is called.

Gumm

Post by Sam Bull

Post by bw
I attached the small program. I'm curious if anyone can run it and
reproduce the problem. I plan on upgrading Ubuntu soon, when I am ready
to risk it: maybe the problem will go away. I'll post the outcome--but
I've been too busy to risk the upgrade, so don't hold yer breath. =)

No idea what the problem could be. I can't reproduce it, but also not
getting more than 130 FPS on my old laptop. I'm curious as to exactly
when it crashes though, can you add some print statements to find
exactly where it crashes?
print("Before")
pygame.quit()
print("After Pygame exit")
quit()
print("Never reached")
I'd also experiment with a couple of different exit functions, to see if
that makes any difference. For example, try removing the pygame.quit()
call (Pygame will exit safely with Python anyway, so it's a redundant
call here), and using sys.exit() instead of the builtin.

[DR0ID]

Post by bw
print(1)
pygame.display.get_init()
print(2)
pygame.display.get_surface()
print(3)
screen.unlock()
print(4)
pygame.display.set_mode((16, 64))
print(5)
pygame.display.flip()
print(6)
pygame.quit()
print(7)
sys.exit()
print(8)
In this sequence it's understood 8 will never be reached. When the
program exits normally 7 is printed and the program terminates. When
the fps gallops away, indicating the problem has occurred, the last
thing printed is always 6 and the program hangs. In all cases the
pygame functions return, except for pygame.quit(). When trying other
exit routines in lieu of pygame.quit() the exiting statement hangs, I
presume because pygame's cleanup is called.
Gumm

Post by Sam Bull

Post by bw
I attached the small program. I'm curious if anyone can run it and
reproduce the problem. I plan on upgrading Ubuntu soon, when I am ready
to risk it: maybe the problem will go away. I'll post the outcome--but
I've been too busy to risk the upgrade, so don't hold yer breath. =)

No idea what the problem could be. I can't reproduce it, but also not
getting more than 130 FPS on my old laptop. I'm curious as to exactly
when it crashes though, can you add some print statements to find
exactly where it crashes?
print("Before")
pygame.quit()
print("After Pygame exit")
quit()
print("Never reached")
I'd also experiment with a couple of different exit
functions, to see if
that makes any difference. For example, try removing the pygame.quit()
call (Pygame will exit safely with Python anyway, so it's a redundant
call here), and using sys.exit() instead of the builtin.

Hi

Could it be that quitting pygame while processing the event queue (well,
the if is in the loop where you process the events) isn't that nice?

Maybe this does not address the actual problem, but might help finding
the problem.

I would prefer something like this (using the pygame.quit *after*
leaving the while loop):

running = True
while running:
...
for event in pygame.event.get():
....
if event.key == K_ESCAPE:
running = False

pygame.quit()
sys.exit()


Also I thought (maybe I'm wrong) that pygame.quit() is registered by
pygame in the 'atexit' module (so no needed to call separately if
quiting the program, of course you need a pygame.quit() if you only want
to quit pygame but keep python running).

I hope that helps

~DR0ID

[bw]

Hi, DR0ID,

While it may not be elegant there is nothing syntactically wrong with
what I did in the event loop. :) When the misbehavior is not occurring
there is no problem exiting the program as it is designed.

To get to the bottom of this I think someone with the right skills and
knowledge would have to dig well beneath the Python code. I lack the
requisites, unfortunately.

Gumm

Post by DR0ID

Post by bw
print(1)
pygame.display.get_init()
print(2)
pygame.display.get_surface()
print(3)
screen.unlock()
print(4)
pygame.display.set_mode((16, 64))
print(5)
pygame.display.flip()
print(6)
pygame.quit()
print(7)
sys.exit()
print(8)
In this sequence it's understood 8 will never be reached. When the
program exits normally 7 is printed and the program terminates. When
the fps gallops away, indicating the problem has occurred, the last
thing printed is always 6 and the program hangs. In all cases the
pygame functions return, except for pygame.quit(). When trying other
exit routines in lieu of pygame.quit() the exiting statement hangs, I
presume because pygame's cleanup is called.
Gumm

Post by Sam Bull

Post by bw
I attached the small program. I'm curious if anyone can run it and
reproduce the problem. I plan on upgrading Ubuntu soon, when I am ready
to risk it: maybe the problem will go away. I'll post the outcome--but
I've been too busy to risk the upgrade, so don't hold yer breath. =)

No idea what the problem could be. I can't reproduce it, but also not
getting more than 130 FPS on my old laptop. I'm curious as to exactly
when it crashes though, can you add some print statements to find
exactly where it crashes?
print("Before")
pygame.quit()
print("After Pygame exit")
quit()
print("Never reached")
I'd also experiment with a couple of different exit
functions, to see if
that makes any difference. For example, try removing the pygame.quit()
call (Pygame will exit safely with Python anyway, so it's a redundant
call here), and using sys.exit() instead of the builtin.

Hi
Could it be that quitting pygame while processing the event queue
(well, the if is in the loop where you process the events) isn't that
nice?
Maybe this does not address the actual problem, but might help finding
the problem.
I would prefer something like this (using the pygame.quit *after*
running = True
...
....
running = False
pygame.quit()
sys.exit()
Also I thought (maybe I'm wrong) that pygame.quit() is registered by
pygame in the 'atexit' module (so no needed to call separately if
quiting the program, of course you need a pygame.quit() if you only
want to quit pygame but keep python running).
I hope that helps
~DR0ID

[B W]

Hey, I bet you forgot about me! :)

I finally upgraded to Ubuntu 14.04. Alas, this problem did not go away.
Since the last message:

- I learned it doesn't matter if FPS is artificially capped; but faster FPS
seems to make the problem occur more reliably. This rules out throttled vs.
un-throttled.
- I learned it doesn't matter if the window is small or big; but smaller
gets faster FPS seems to make the problem occur more reliably. This may
rule out total blit calls and total pixels per frame.
- I learned it doesn't matter if the game uses the local display or remote
over a SSH tunnel. I think this rules out video drivers.
- incorporated the feedback from DR0ID, to put the exit calls outside the
main loop.
- incorporated the feedback from Sam, to use print statements to show exit
progress.

The issue seems to be in the shutdown/cleanup code of pygame. Yet, as I
indicated before the strange behavior (sudden permanent boost in FPS) is
observed well before program exit. Although this is harder to spot in
Ubuntu 14.04 because I'm getting near max FPS from the beginning.

The updated program is attached.

Gumm

Post by bw
Hi, DR0ID,
While it may not be elegant there is nothing syntactically wrong with what
I did in the event loop. :) When the misbehavior is not occurring there is
no problem exiting the program as it is designed.
To get to the bottom of this I think someone with the right skills and
knowledge would have to dig well beneath the Python code. I lack the
requisites, unfortunately.
Gumm

Post by DR0ID

Post by bw
print(1)
pygame.display.get_init()
print(2)
pygame.display.get_surface()
print(3)
screen.unlock()
print(4)
pygame.display.set_mode((16, 64))
print(5)
pygame.display.flip()
print(6)
pygame.quit()
print(7)
sys.exit()
print(8)
In this sequence it's understood 8 will never be reached. When the
program exits normally 7 is printed and the program terminates. When the
fps gallops away, indicating the problem has occurred, the last thing
printed is always 6 and the program hangs. In all cases the pygame
functions return, except for pygame.quit(). When trying other exit routines
in lieu of pygame.quit() the exiting statement hangs, I presume because
pygame's cleanup is called.
Gumm

Post by Sam Bull

Post by bw
I attached the small program. I'm curious if anyone can run it and
reproduce the problem. I plan on upgrading Ubuntu soon, when I am ready
to risk it: maybe the problem will go away. I'll post the outcome--but
I've been too busy to risk the upgrade, so don't hold yer breath. =)

No idea what the problem could be. I can't reproduce it, but also not
getting more than 130 FPS on my old laptop. I'm curious as to exactly
when it crashes though, can you add some print statements to find
exactly where it crashes?
print("Before")
pygame.quit()
print("After Pygame exit")
quit()
print("Never reached")
I'd also experiment with a couple of different exit functions, to see if
that makes any difference. For example, try removing the pygame.quit()
call (Pygame will exit safely with Python anyway, so it's a redundant
call here), and using sys.exit() instead of the builtin.

Hi

Could it be that quitting pygame while processing the event queue (well,
the if is in the loop where you process the events) isn't that nice?
Maybe this does not address the actual problem, but might help finding
the problem.
I would prefer something like this (using the pygame.quit *after* leaving
running = True
...
....
running = False
pygame.quit()
sys.exit()
Also I thought (maybe I'm wrong) that pygame.quit() is registered by
pygame in the 'atexit' module (so no needed to call separately if quiting
the program, of course you need a pygame.quit() if you only want to quit
pygame but keep python running).
I hope that helps
~DR0ID

[Sam Bull]

Post by B W
The issue seems to be in the shutdown/cleanup code of pygame.

The program appears to only use the pygame.display module, so if it is
currently crashing in pygame.exit(), then it may be an idea to try
initialising and exiting individual modules, to see if the problem is in
a single module's shutdown.

So, replace pygame.init() with pygame.display.init(), and pygame.quit()
with pygame.display.quit(). If the crash disappears, then start adding
additional module init's and quit's and see if you can narrow the crash
into a single module's quit() function. Other modules include
pygame.mixer and pygame.scrap.

[B W]

Argh! pygame.mixer.quit() is hanging.

('keydown', 'escape')
Exit progress: begin
Exit progress: pygame.display.get_init()
Exit progress: pygame.display.get_surface()
Exit progress: screen.unlock()
Exit progress: pygame.display.set_mode((16, 64))
Exit progress: pygame.display.flip()
Exit progress: pygame.display.quit()
Exit progress: pygame.mixer.quit()

Gumm

Post by Sam Bull

Post by B W
The issue seems to be in the shutdown/cleanup code of pygame.

The program appears to only use the pygame.display module, so if it is
currently crashing in pygame.exit(), then it may be an idea to try
initialising and exiting individual modules, to see if the problem is in
a single module's shutdown.
So, replace pygame.init() with pygame.display.init(), and pygame.quit()
with pygame.display.quit(). If the crash disappears, then start adding
additional module init's and quit's and see if you can narrow the crash
into a single module's quit() function. Other modules include
pygame.mixer and pygame.scrap.

[a***@public.gmane.org]

The same has been happening to me since an update of Ubuntu and I think it's a problem with pulseaudio.

Since this started, very occasionally I get errors involving asserts in pulseaudio's main loop, and I've googled up a couple of posts about those errors, which suggest that pygame is doing something unorthodox with the threading that throws it off.

I haven't tried the solutions proposed for previous problems with pygame and pulseaudio yet.

Hasvers

----- Mail original -----
De: "B W" <stabbingfinger-***@public.gmane.org>
À: "N:" <pygame-users-***@public.gmane.org>
Envoyé: Mercredi 16 Juillet 2014 18:10:41
Objet: Re: [pygame] This program breaks on my Linux



Argh! pygame.mixer.quit() is hanging.

('keydown', 'escape')
Exit progress: begin
Exit progress: pygame.display.get_init()
Exit progress: pygame.display.get_surface()
Exit progress: screen.unlock()
Exit progress: pygame.display.set_mode((16, 64))
Exit progress: pygame.display.flip()
Exit progress: pygame.display.quit()
Exit progress: pygame.mixer.quit()

Gumm

Post by B W
The issue seems to be in the shutdown/cleanup code of pygame.

The program appears to only use the pygame.display module, so if it is
currently crashing in pygame.exit(), then it may be an idea to try
initialising and exiting individual modules, to see if the problem is in
a single module's shutdown.

So, replace pygame.init() with pygame.display.init(), and pygame.quit()
with pygame.display.quit(). If the crash disappears, then start adding
additional module init's and quit's and see if you can narrow the crash
into a single module's quit() function. Other modules include
pygame.mixer and pygame.scrap.

[Sam Bull]

Post by B W
Argh! pygame.mixer.quit() is hanging.

If you're comfortable with compiling pygame, then I'd keep drilling
down, sprinkling more prints into mixer.c/autoquit() to see which line
of that function it fails on. The last line appears to tell SDL to
shutdown, so if it fails at that line, I would assume the error is in
SDL.

[Jake b]

SIGTERM (15) does not kill the program. SIGKILL (9) does.

You need to handle event QUIT.

[bw]

Hi, Jake,

This is not true. A process's default action for an unhandled event is
to abort. During normal execution, when the problem is not occurring, an
unhandled SIGTERM aborts the process just fine.

Gumm

Post by Jake b

SIGTERM (15) does not kill the program. SIGKILL (9) does.

You need to handle event QUIT.