Crash in SDL_mixer post-mixing callback on x86 Mac running XP

The sound code of my Doom port, the Eternity Engine, is crashing
for one of my users who is running XP on an x86 Mac machine. When
compiled using SDL 1.2.10 and SDL_mixer 1.2.7, the program suffers
a crash at a seemingly arbitrary point within the post-mix callback
function. The game actually remains playable, but the standard
Windows error report dialog appears over the screen and the sound
begins to constantly repeat the last bytes of sound played. When
compiled with SDL 1.2.11, the main game thread also locks up.

The application error reported is 0xc0000005 (a memory access error
according to MSDN).

Here is a screenshot of the error happening:
http://sl4.dmclub.org/ee_error.png

And in this folder are some shots of the error report:
http://sl4.dmclub.org/wads/ee-error/

The error seems to occur within the function I_SDLUpdateSound
(this is the closest symbol to the crash address found in the map file
generated by Visual C++). That function can be found in this file:

http://eternity.mancubus.net/svn/trunk/eternity/source/i_sound.c

I cannot make any inroads against this problem, since the crash is
only occurring for this particular user. Literally thousands of man hours
of play testing have gone into the game without this error ever
occuring elsewhere, so I’m hesitant to blame my own code. If
anyone has any clues as to what could cause this, I’d be highly
appreciative.

Yours,
James Haley_________________________________________________________________
Need a break? Find your escape route with Live Search Maps.
http://maps.live.com/?icid=hmtag3

Woops, I left out part of the URL to the source file
in my first message. Here’s the correct URL:

http://eternity.mancubus.net/svn/trunk/eternity/source/sdl/i_sound.c

Sorry about that :wink:

James Haley_________________________________________________________________
Download Messenger. Join the i?m Initiative. Help make a difference today.
http://im.live.com/messenger/im/home/?source=TAGHM_APR07

James Haley wrote:

The sound code of my Doom port, the Eternity Engine, is crashing
for one of my users who is running XP on an x86 Mac machine. When
compiled using SDL 1.2.10 and SDL_mixer 1.2.7, the program suffers
a crash at a seemingly arbitrary point within the post-mix callback
function. The game actually remains playable, but the standard
Windows error report dialog appears over the screen and the sound
begins to constantly repeat the last bytes of sound played. When
compiled with SDL 1.2.11, the main game thread also locks up.

The application error reported is 0xc0000005 (a memory access error
according to MSDN).

Here is a screenshot of the error happening:
http://sl4.dmclub.org/ee_error.png

And in this folder are some shots of the error report:
http://sl4.dmclub.org/wads/ee-error/

The error seems to occur within the function I_SDLUpdateSound
(this is the closest symbol to the crash address found in the map file
generated by Visual C++). That function can be found in this file:

http://eternity.mancubus.net/svn/trunk/eternity/source/i_sound.c

I cannot make any inroads against this problem, since the crash is
only occurring for this particular user. Literally thousands of man hours
of play testing have gone into the game without this error ever
occuring elsewhere, so I’m hesitant to blame my own code. If
anyone has any clues as to what could cause this, I’d be highly
appreciative.

I’m wondering if he’s got an onboard audio chip that can only ever do
48000Hz for a sample rate…SDL would probably be trying to upsample,
incorrectly, from 44100Hz.

SDL 1.2 is buggy when resampling from rates that aren’t multiples…so
it could do 24000Hz to 48000Hz or 48000Hz to 96000Hz, but 44100 to 48000
would probably cause an internal buffer in SDL to overflow.

Add a call to Mix_QuerySpec() in there after the Mix_OpenAudio() call
and see what it reports. Consider failing to initialize the game’s audio
subsystem if Mix_QuerySpec() doesn’t report a frequency that
snd_samplerate is a multiple of (or vice versa)…at least, until
someone fixes that bug in SDL. Hell, SDL should probably just fail in
this case, in the meantime, too.

Based on a first look at your code, that would be my best guess. Most
audio hardware can do 41000Hz, but I’ve seen motherboard chips that can
only do 48000, and you might have just stumbled upon one for the first time.

–ryan.

Looks like no dice on the sampling frequency idea. I had him run
a new compile modified to print the information returned by
Mix_QuerySpec and it gives this:

Mix_QuerySpec: fmt=S16LSB, freq=44100, chans=2

This seems to be the same as the format requested in the call
to Mix_OpenAudio. Thanks for the suggestion, however. It’s
always useful to rule things out.

James>From: “Ryan C. Gordon”

Reply-To: “A list for developers using the SDL library. (includes
SDL-announce)”
To: "A list for developers using the SDL library. (includes SDL-announce)"

Subject: Re: [SDL] Crash in SDL_mixer post-mixing callback on x86 Mac
running XP
Date: Mon, 09 Apr 2007 00:57:06 -0400
MIME-Version: 1.0
Received: from diego.dreamhost.com ([66.33.216.104]) by
bay0-mc12-f5.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 8
Apr 2007 21:57:11 -0700
Received: from diego.dreamhost.com (localhost [127.0.0.1])by
diego.dreamhost.com (Postfix) with ESMTP id 9340F48006;Sun, 8 Apr 2007
21:57:09 -0700 (PDT)
Received: from icculus.org (icculus.org [67.106.77.212])by
diego.dreamhost.com (Postfix) with ESMTP id 5C0B048002for
; Sun, 8 Apr 2007 21:57:07 -0700 (PDT)
Received: (qmail 9197 invoked by uid 305); 9 Apr 2007 00:56:23 -0400
Received: from icculus at icculus.org by gamehenge by uid 305
withqmail-scanner-1.22 (clamdscan: 0.75.1. Clear:RC:1(75.181.37.52):.
Processed in 0.029067 secs); 09 Apr 2007 04:56:23 -0000
Received: from unknown (HELO ?192.168.1.121?) (icculus at 75.181.37.52)by
icculus.org with ESMTPA; 9 Apr 2007 00:56:23 -0400
X-Message-Info:
5ZHoJh3ZkQ24jQa8V5dSgAxRx9bZEfiRqwyn+k4XmIIILxjswsa8701qz0Vs2EBI
X-Original-To: sdl at lists.libsdl.org
Organization: icculus.org
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
References:
X-BeenThere: sdl at lists.libsdl.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: “A list for developers using the SDL library.
(includesSDL-announce)” <sdl-libsdl.org>
List-Unsubscribe:
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org,<mailto:sdl-request at lists.libsdl.org?subject=unsubscribe>
List-Archive: http://lists.libsdl.org/pipermail/sdl-libsdl.org
List-Post: <mailto:sdl at lists.libsdl.org>
List-Help: <mailto:sdl-request at lists.libsdl.org?subject=help>
List-Subscribe:
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org,<mailto:sdl-request at lists.libsdl.org?subject=subscribe>
Errors-To: sdl-bounces at lists.libsdl.org
Return-Path: sdl-bounces at lists.libsdl.org
X-OriginalArrivalTime: 09 Apr 2007 04:57:11.0380 (UTC)
FILETIME=[88802940:01C77A63]

James Haley wrote:

The sound code of my Doom port, the Eternity Engine, is crashing
for one of my users who is running XP on an x86 Mac machine. When
compiled using SDL 1.2.10 and SDL_mixer 1.2.7, the program suffers
a crash at a seemingly arbitrary point within the post-mix callback
function. The game actually remains playable, but the standard
Windows error report dialog appears over the screen and the sound
begins to constantly repeat the last bytes of sound played. When
compiled with SDL 1.2.11, the main game thread also locks up.

The application error reported is 0xc0000005 (a memory access error
according to MSDN).

Here is a screenshot of the error happening:
http://sl4.dmclub.org/ee_error.png

And in this folder are some shots of the error report:
http://sl4.dmclub.org/wads/ee-error/

The error seems to occur within the function I_SDLUpdateSound
(this is the closest symbol to the crash address found in the map file
generated by Visual C++). That function can be found in this file:

http://eternity.mancubus.net/svn/trunk/eternity/source/i_sound.c

I cannot make any inroads against this problem, since the crash is
only occurring for this particular user. Literally thousands of man
hours
of play testing have gone into the game without this error ever
occuring elsewhere, so I’m hesitant to blame my own code. If
anyone has any clues as to what could cause this, I’d be highly
appreciative.

I’m wondering if he’s got an onboard audio chip that can only ever do
48000Hz for a sample rate…SDL would probably be trying to upsample,
incorrectly, from 44100Hz.

SDL 1.2 is buggy when resampling from rates that aren’t multiples…so
it could do 24000Hz to 48000Hz or 48000Hz to 96000Hz, but 44100 to 48000
would probably cause an internal buffer in SDL to overflow.

Add a call to Mix_QuerySpec() in there after the Mix_OpenAudio() call
and see what it reports. Consider failing to initialize the game’s audio
subsystem if Mix_QuerySpec() doesn’t report a frequency that
snd_samplerate is a multiple of (or vice versa)…at least, until
someone fixes that bug in SDL. Hell, SDL should probably just fail in
this case, in the meantime, too.

Based on a first look at your code, that would be my best guess. Most
audio hardware can do 41000Hz, but I’ve seen motherboard chips that can
only do 48000, and you might have just stumbled upon one for the first
time.

–ryan.


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


Get a FREE Web site, company branded e-mail and more from Microsoft Office
Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/

This seems to be the same as the format requested in the call
to Mix_OpenAudio. Thanks for the suggestion, however. It’s
always useful to rule things out.

hhm, okay. I really would have guessed that to be the culprit, sorry
about that.

Try forcing it to use waveout instead of DirectSound, in case it’s a
hardware driver bug.

Set the environment variable: SDL_AUDIODRIVER=waveout

You’ll know it worked with this:

 char buf[64];
 SDL_AudioDriverName(buf, sizeof (buf));
 printf("Using SDL audio driver '%s'\n", buf);

(printf() being, of course, whatever you use for a console in the engine.)

If the environment variable isn’t set, it’ll default to DirectSound
(Windows can be bitchy about setting environment vars inside the
program, I’ve been told)…if you set it to something bogus,
SDL_Init(SDL_INIT_AUDIO) will fail, so you’ll at least know if it picked
up the var without a new build. If that printf says “waveout” it got it,
if it says something like “dsound” it ignored the variable.

He can do this without a new build if he’s comfortable with the command
prompt in Windows:

set SDL_AUDIODRIVER=waveout
eternity.exe

If that solves the problem, it’s his hardware drivers and there’s not
much you can do (except maybe add a cvar to choose a specific SDL
backend and a troubleshooting FAQ about it). If it’s still hosed, I’d
really need some heavy debugging work on his box to get further…and
maybe someone should push Eternity’s SDL audio code through valgrind or
purify or whatnot just to make sure it’s not overflowing a buffer.

–ryan.