Mysterious crash with SDL_mixer

SDL Development
1

Hi,
I just switched from OpenAL to SDL_mixer. Now I have an intermittent
crash that happens only in the release build on Windows; not in debug
:frowning: and not on Linux. Building a simple test program would not
duplicate the problem. I can duplicate it only about half the time by
blowing up the same series of evil aliens when my game starts. Iā€™m
using current SDL_mixer and very close to current SDL from svn.

If I comment out my call to MIX_SetPanning(), the problem goes away.
So I dug deeper and found that it also goes away if I remove this
chunk of code that assigns effects in _Mix_register_effect():

if (*e == NULL) {
*e = new_e;
} else {
effect_info *cur = *e;
while (1) {
if (cur->next == NULL) {
cur->next = new_e;
break;
}
cur = cur->next;
}
}

Unfortunately, I havenā€™t been able to narrow it down to any particular
part of the effect handling code. And with a bug like this (probably
some nasty invalid pointer somwhere), thereā€™s no way to know if the
problem is in SDL_mixer or if it has been lurking somewhere else in my
game code for a long time.

Anyone else having any trouble like this, or have any suggestion for
me? Iā€™ve tried everything I can think of so far.ā€“
Terry

P.S. The malloc at the start of _Mix_register_effect() should
probably be moved down a few lines past all the return statements to
avoid a memory leak.

2

First time i used SDL_mixer on windows, it crashed too. But after i installed mikmod.dll it worked. Make sure mikmod.dll is in the folder in which your application is.

3

Okay, so after a lot more digging I found the culprit. In
SDL_audiotypecvt.c there are a lot of lines like this:

while (dst != target) {

Sometimes dst with blow right past target and cause array overflows.
So after changing all of those lines to

while (dst < target) {

or

while (dst > target) {

depending on whether the function is for oversampling or
undersampling, everything seems to work. I donā€™t know if every one of
these resampling functions have this problem, but at least some do.

One in particular is in SDL_Downsample_S16LSB_2c(). I was able to get
this one to barf by loading a 48kHz sound after calling Mix_OpenAudio
with a frequency of 44.1kHz.

I donā€™t know enough about how these resampling functions are supposed
to behave. Does this correction sound reasonable, or am I missing
something?ā€“
Terry

On Wed, Dec 16, 2009 at 11:21 PM, Terry Welsh <@Terry_Welsh> wrote:

Hi,
I just switched from OpenAL to SDL_mixer. Now I have an intermittent
crash that happens only in the release build on Windows; not in debug
:frowning: and not on Linux. Building a simple test program would not
duplicate the problem. I can duplicate it only about half the time by
blowing up the same series of evil aliens when my game starts. Iā€™m
using current SDL_mixer and very close to current SDL from svn.

If I comment out my call to MIX_SetPanning(), the problem goes away.
So I dug deeper and found that it also goes away if I remove this
chunk of code that assigns effects in _Mix_register_effect():

if (*e == NULL) {
*e = new_e;
} else {
effect_info *cur = *e;
while (1) {
if (cur->next == NULL) {
cur->next = new_e;
break;
}
cur = cur->next;
}
}

Unfortunately, I havenā€™t been able to narrow it down to any particular
part of the effect handling code. And with a bug like this (probably
some nasty invalid pointer somwhere), thereā€™s no way to know if the
problem is in SDL_mixer or if it has been lurking somewhere else in my
game code for a long time.

Anyone else having any trouble like this, or have any suggestion for
me? Iā€™ve tried everything I can think of so far.

Terry

P.S. The malloc at the start of _Mix_register_effect() should
probably be moved down a few lines past all the return statements to
avoid a memory leak.

4

This sounds great. Can you enter a bug with this info into bugzilla?
http://bugzilla.libsdl.org/

Thanks!On Thu, Dec 17, 2009 at 10:55 PM, Terry Welsh wrote:

Okay, so after a lot more digging I found the culprit. ?In
SDL_audiotypecvt.c there are a lot of lines like this:

while (dst != target) {

Sometimes dst with blow right past target and cause array overflows.
So after changing all of those lines to

while (dst < target) {

or

while (dst > target) {

depending on whether the function is for oversampling or
undersampling, everything seems to work. ?I donā€™t know if every one of
these resampling functions have this problem, but at least some do.

One in particular is in SDL_Downsample_S16LSB_2c(). ?I was able to get
this one to barf by loading a 48kHz sound after calling Mix_OpenAudio
with a frequency of 44.1kHz.

I donā€™t know enough about how these resampling functions are supposed
to behave. ?Does this correction sound reasonable, or am I missing
something?

Terry

On Wed, Dec 16, 2009 at 11:21 PM, Terry Welsh wrote:

Hi,
I just switched from OpenAL to SDL_mixer. ?Now I have an intermittent
crash that happens only in the release build on Windows; not in debug
:frowning: and not on Linux. ?Building a simple test program would not
duplicate the problem. ?I can duplicate it only about half the time by
blowing up the same series of evil aliens when my game starts. ?Iā€™m
using current SDL_mixer and very close to current SDL from svn.

If I comment out my call to MIX_SetPanning(), the problem goes away.
So I dug deeper and found that it also goes away if I remove this
chunk of code that assigns effects in _Mix_register_effect():

if (*e == NULL) {
? ? ? ? ? ? ? ?*e = new_e;
? ? ? ?} else {
? ? ? ? ? ? ? ?effect_info *cur = *e;
? ? ? ? ? ? ? ?while (1) {
? ? ? ? ? ? ? ? ? ? ? ?if (cur->next == NULL) {
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?cur->next = new_e;
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?break;
? ? ? ? ? ? ? ? ? ? ? ?}
? ? ? ? ? ? ? ? ? ? ? ?cur = cur->next;
? ? ? ? ? ? ? ?}
? ? ? ?}

Unfortunately, I havenā€™t been able to narrow it down to any particular
part of the effect handling code. ?And with a bug like this (probably
some nasty invalid pointer somwhere), thereā€™s no way to know if the
problem is in SDL_mixer or if it has been lurking somewhere else in my
game code for a long time.

Anyone else having any trouble like this, or have any suggestion for
me? ?Iā€™ve tried everything I can think of so far.

Terry

P.S. ?The malloc at the start of _Mix_register_effect() should
probably be moved down a few lines past all the return statements to
avoid a memory leak.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

ā€“
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

5

Okay, so after a lot more digging I found the culprit. In
SDL_audiotypecvt.c there are a lot of lines like this:

Iā€™m poking around this code today, so this will be fixed in revision
control soon.

ā€“ryan.

6

Thanks Ryan. And I already submitted this as bug #911 at Samā€™s
request, just so you knowā€¦ā€“
Terry

Message: 6
Date: Tue, 22 Dec 2009 13:48:15 -0500
From: ā€œRyan C. Gordonā€
To: SDL Development List
Subject: Re: [SDL] mysterious crash with SDL_mixer
Message-ID: <4B31146F.7060804 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Okay, so after a lot more digging I found the culprit. ?In
SDL_audiotypecvt.c there are a lot of lines like this:

Iā€™m poking around this code today, so this will be fixed in revision
control soon.

ā€“ryan.

7

Hi Ryan. I just check your fixes to SDL_audiotypecvt.c out of SVN.
Is there a reason you changed some but not all of the "dst != target"
lines? The one on line 3854 is still causing me trouble. I imagine
some or most of those functions work fine, but I sure donā€™t know which
ones.ā€“
Terry

On Tue, Dec 22, 2009 at 11:39 AM, Terry Welsh <@Terry_Welsh> wrote:

Thanks Ryan. ?And I already submitted this as bug #911 at Samā€™s
request, just so you knowā€¦

Terry

Message: 6
Date: Tue, 22 Dec 2009 13:48:15 -0500
From: ā€œRyan C. Gordonā€
To: SDL Development List
Subject: Re: [SDL] mysterious crash with SDL_mixer
Message-ID: <4B31146F.7060804 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Okay, so after a lot more digging I found the culprit. ?In
SDL_audiotypecvt.c there are a lot of lines like this:

Iā€™m poking around this code today, so this will be fixed in revision
control soon.

ā€“ryan.