Audio crash in memfree with minigame (6.6.0e)

[mrsulu]

I have a minigame that I'm running in a python hide:

Code: Select all

    python hide:
        pm = PongMinigame( "Marie/temple800x600color.png", 5, 5 )
        pm.minigame.run()

    return

(It's not actually pong.)

This works fine unless, within the minigame, I do:

Code: Select all

            def event(self, ev, x, y, st):

                import pygame

              # blah blah some stuff


               if ev.type == pygame.MOUSEBUTTONUP and self.starting == 1:
                    renpy.music.set_volume(1.0, channel=7)
                    renpy.music.play("sound/puzzleSolver-short2.mp3", loop=True)

If I have the renpy.music.play() it starts the music, plays fine, and then I stop it before quitting the minigame.

However, upon quitting the entire game, it then crashes (traceback from Linux):

Code: Select all

*** glibc detected *** /tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/python.real: double free or corruption (out): 0x0848f7f8 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7d62d65]
/lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7d66800]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libSDL-1.2.so.0[0xb7b86712]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libSDL-1.2.so.0(SDL_AudioQuit+0xc7)[0xb7b461de]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libSDL-1.2.so.0(SDL_QuitSubSystem+0x9c)[0xb7b44b8a]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libSDL-1.2.so.0(SDL_CloseAudio+0x1e)[0xb7b46111]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/python2.5/pysdlsound/sound.so(PSS_quit+0xb0)[0xb75ae6b5]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/python2.5/pysdlsound/sound.so[0xb75af7e8]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libpython2.5.so.1.0(PyCFunction_Call+0x118)[0xb7eeea0b]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libpython2.5.so.1.0(PyObject_Call+0x33)[0xb7ebaf1e]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x3e7f)[0xb7f38524]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x70b)[0xb7f3b65d]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libpython2.5.so.1.0[0xb7edb7e5]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libpython2.5.so.1.0(PyObject_Call+0x33)[0xb7ebaf1e]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libpython2.5.so.1.0(PyEval_CallObjectWithKeywords+0x76)[0xb7f33a88]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libpython2.5.so.1.0(Py_Finalize+0x65)[0xb7f5cea7]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libpython2.5.so.1.0(Py_Exit+0x17)[0xb7f5c373]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libpython2.5.so.1.0[0xb7f5c45b]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libpython2.5.so.1.0(PyErr_PrintEx+0x1a9)[0xb7f5c698]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libpython2.5.so.1.0(PyErr_Print+0x1e)[0xb7f5c8a5]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libpython2.5.so.1.0(PyRun_SimpleFileExFlags+0xf5)[0xb7f5c9a0]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libpython2.5.so.1.0(PyRun_AnyFileExFlags+0x6e)[0xb7f5dfcb]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/lib/libpython2.5.so.1.0(Py_Main+0xb66)[0xb7f67c2c]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/python.real(main+0x2a)[0x804855e]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7d0f050]
/tmp/sugarplum-1.0RC1-linux-x86/lib/linux-x86/python.real[0x80484b5]

If I comment out the music.play() it doesn't crash.

Help!

[PyTom]

I've seen this before, but haven't been able to find out what causes it. (Probably something to do with how we denitialize the sound system... sometime I need to take another look.)

[mrsulu]

Is there a quit hook I can just system.exit(0) out of? I know it's not nice to let it all just explode, but I believe SDL can handle suddenly slamming the door shut.

It would certainly be more pleasant than crashing.

[PyTom]

Not really, since Ren'Py uses it to do a safe shutdown. I'll take a look at this soon, and see if I can make it go away.

[mrsulu]

I have one more hint on finding it:

I think you have to enter the minigame twice to set it off, but I could verify that. I'm playing the same song both times, so idly I was wondering if you're caching the song somehow and when you go to the minigame, you're seeing the same filename so you're making another hook to the same part of the cache. However, I'm just guessing.

That would be great if there's a fix soon. This is the last bug that I know of in my game. Thanks!

[PyTom]

Hm... I'm having trouble repeating it. Can you send me a testcase, along with instructions on how to repeat it? Thanks.