This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.0
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2013-02-01 07:28:29 +0000, Andreas Schiffler wrote:

Running the audio test audio_convertAudio in automation by running:
./testautomation --filter audio_convertAudio
or
gdb ./testautomation
(gdb) run --filter audio_convertAudio
consistently segfaults.

...
INFO: 02/01/13 15:25:26: Assert 'Call to SDL_BuildAudioCVT(format[17]=AUDIO_F32(33056),channels[3]=6,freq[2]=44100 ==> format[13]=AUDIO_S32(32800),channels[3]=6,freq[2]=44100)': Pass
INFO: 02/01/13 15:25:26: Assert 'Verify result value; expected: 1, got: 1': Passed
INFO: 02/01/13 15:25:26: Assert 'Verify that cvt.len_mult value; expected: >0, got: 1': Passed
INFO: 02/01/13 15:25:26: Creating dummy sample buffer of 64 length (64 bytes)
INFOSegmentation fault

...
warning: INFO: 02/01/13 15:26:54: Assert 'Call to SDL_BuildAudioCVT(format[0]=AUDIO_S8(32776),channels[1]=2,freq[1]=22050 ==> format[1]=AUDIO_U8(8),channels[3]=6,freq[1]=22050)': Pass
warning: INFO: 02/01/13 15:26:54: Assert 'Verify result value; expected: 1, got: 1': Passed
warning: INFO: 02/01/13 15:26:54: Assert 'Verify that cvt.len_mult value; expected: >0, got: 3': Passed
warning: INFO: 02/01/13 15:26:54: Creating dummy sample buffer of 64 length (192 bytes)
warning: INFO: 02/01/13 15:26:54: Assert 'Check data buffer to convert is not NULL': Passed

Program received signal SIGSEGV, Segmentation fault.
0x765e1a01 in msvcrt!_HUGE () from /cygdrive/c/Windows/syswow64/msvcrt.dll

It looks like from a few retries, that this occurs when the source and/or target channel count is "6" (surround).

This repros on Win7/cygwin/64bit and Linux/Ubuntu/64bit.

Note: To get the correct crashdump on Linux, one needed to enable the currently disabled test case at the end of the file testautomation_audio.c and recompile the testautomation binary.

On 2013-07-12 18:52:47 +0000, Ryan C. Gordon wrote:

(Sorry if you get a lot of copies of this email, we're touching dozens of bug reports right now.)

Tagging a bunch of bugs as target-2.0.0, Priority 1.

This means we're in the final stretch for an official SDL 2.0.0 release! These are the bugs we really want to fix before shipping if humanly possible.

That being said, we don't promise to fix them because of this tag, we just want to make sure we don't forget to deal with them before we bless a final 2.0.0 release, and generally be organized about what we're aiming to ship.

Hopefully you'll hear more about this bug soon. If you have more information (including "this got fixed at some point, nevermind"), we would love to have you come add more information to the bug report when you have a moment.

Thanks!
--ryan.

On 2018-08-06 21:20:20 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.