[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] BUG:? pygame.mixer.music crash



This SDL_mixer bug was fixed in SVN. The test cases attached to the original post run with crashing for a new SDL_mixer.dll built fresh from SVN. The new SDL_mixer for Windows will be included in the next Pygame release, hopefully a 1.8 bug fix coming shortly.

Lenard


claudio canepa wrote:

Problem:

pygame.mixer.music crash while changing song

pygame versions with problems:

1.7.1 : got from pygame site maybe two years ago, the binary dependencies at same time , the binaries readme tells it is SDL - 1.2.7 , with SDL_mixer - 1.2.3, built with MSVC 6. Lots of pygame games run with no problems.

1.8.1.rc3 : test 1 both with the telus build and the 'automated build', tests 2 and 3 only tested against telus build

Other info:
winXP + sp2, python 2.4.3, integrated audio nvidia nforce2, audio drivers version 5.10.2917.0
Tested on more than a single machine, but same hardware.

Problem - bugdemos history:

1. I am one of the magicor (http://magicor.sourceforge.net <http://magicor.sourceforge.net/>) developers, working in windows; with pygame 1.7.1 no real problems with the game, but trying the pygame 1.8.1.rc3 crashes begin. I tracked the problem to the moment pygame.mixer.music is instructed to change the current song. The crash is a GPF, not even a 'pygame parachute', and the OS tell the fault is at sdl_mixer.dll , vs 1.2.8.0 <http://1.2.8.0> ( provided with the windows installer for pygame 1.8.1.rc3 ) The specific fail moment is when in the levelselect menu the user gives an 'esc', wich normally will change to the main menu. I tryied with both the telus build and the 'automated build', same problem. 1.8.1.rc3 installed after unistall 1.7.1 and deleting the remaining site-packages\pygame dir

2. Then I wrote mtest2.py (atached) to demo the problem in short code; it responds to keypresess changing or restarting the song played. ( to try it you must get two songs from the magicor repo, data\music\menu.xm and data\levels\egypt\egyptian-trance.xm ) All right, at first seemed to worked as expected: no fail in 1.7.1, fail in 1.8.1.rc3. With more runs, they start to appear crashes in 1.7.1, albeit mostly 'pygame parachute's. Failures not so consistent. Maybe sensitive to the timming of keypresses, sometimes closing a console and starting other seems to help to get failures. Restarting ( keypress 'r' ) seems more prone to crash than toggle song ( keypress 't' ) in pygame 1.7.1, the other way with 1.8.1.rc3 the song 'egyptian-trance.xm' seems to crash more than menu.xm ( in repeat mode ) Two or tree toggles in 1.8.1.rc3 usually suffice to crash, 1.7.1 seems les prone to crash.

3. To have a better testbed for posible workarounds, I wrote a test that colects some stats.
trunner2.py (the test runner) and ,mtest4.py ( the test ) - both atached.

trunner2 will run k-times mtest4.py as a subprocess, counting the crashes.
mtest4.py is an automated mtest2.py, it attempts to do a programable count of song changes, be it by restarting the same sound or changing to the other. If not crashed, will add a line to a log file. ( Note: that works well with 1.7.1, but in 1.8.1.rc3 you must close manually the OS messagebox that informs about the gpf )
Finally trunner will report the stats.

That was better, but I suspect the test is introducing some artifacts. Specifically, the failure ratio for 1.7.1 seems too high ( 22/25 , 24/25 for song 'egyptian-trance.xm , 12/25 for 'menu.xm', change_mode as restart same song ). And seems that if run k fails then run k+1 probably will fail. Suspecting an OS cleanup after crash can interfere, I added a litle wait between test runs, thats the time_sleep in trunner2.py . With it, failures goes down to 1/25 , 0/25 , more reasonable in the light that magicor doenst crash with 1.7.1


Some results:

---
Trunner2 results wwith pygame 1.7.1
run1:
initial song: 1
change mode is toggle: 1
time_sleep: None
runs: 25
changes per runs: 10
success: 3
failed: 22

run2:
initial song: 1
change mode is toggle: 1
time_sleep: 0.5
runs: 25
changes per runs: 10
success: 25
failed: 0

initial song: 1
change mode is toggle: 0
time_sleep: 0.5
runs: 25
changes per runs: 10
success: 25
failed: 0

initial song: 1
change mode is toggle: 0
time_sleep: None
runs: 25
changes per runs: 10
success: 3
failed: 22

------------
Trunner2 results wwith pygame 1.8.1.rc3
initial song: 1
change mode is toggle: 1
time_sleep: None
runs: 25
changes per runs: 10
success: 0
failed: 25

initial song: 1
change mode is toggle: 1
time_sleep: 0.5
runs: 25
changes per runs: 10
success: 0
failed: 25

initial song: 1
change mode is toggle: 0
time_sleep: 0.5
runs: 25
changes per runs: 10
success: 25
failed: 0

-------------

Allright, I will try to build some workaround and report.
If there is some sugestion from the pygame builders I will be glad to test. Be patient with the mail, Im working out of town and checking mail at a cybercafe once a day.

--
claxo



--
Lenard Lindstrom
<len-l@xxxxxxxxx>