| Summary: | Segmentation fault on playing sounds | ||
|---|---|---|---|
| Product: | SDL_mixer | Reporter: | Carl Castanier <woodswolf> |
| Component: | misc | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED WORKSFORME | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | roguebooth, tigerfishdaisy |
| Version: | 1.2.8 | ||
| Hardware: | x86 | ||
| OS: | Windows (XP) | ||
|
Description
Carl Castanier
2008-01-09 03:46:47 UTC
This bug report may be a duplicate of 539 - Segmentation fault on playing sounds. However, I can give a specific procedure to quickly and easily replicate the crash. I created a standard Single-Document-Interface Windows SDK application. In WinMain, before creating the main window, I initialized SDL and after the main loop exited, I shut down SDL. One menu option invoked a dialog. On this dialog were three buttons, although two would be sufficient. Two of the the three buttons on the dialog were set up to play wave files using Mix_LoadWAV() and Mix_PlayChannel(). The third was set up to play a .MP3 file using Mix_LoadMUS() and Mix_PlayMusic(). I used a Windows timer to poll for the end of the .MP3 file, calling Mix_PlayingMusic() on each timer message. The button to play the .MP3 was disabled while the .MP3 file was being played. I found that I could start up many of the wave files in rapid succession, such that I could hear them overlapping each other - that part worked fine. I found that I could play the .MP3 file in succession many times without problems. The fact that the button to play the .MP3 was disabled until the file was finished playing kept me from mixing two .MP3 files together, which I assume is beyond the capabilities of SDL_mixer. No complaints there. I am able to trigger the bug very regularly (not every time, but most times) by playing a wave file, and while the wave file is still playing, start to play the .MP3 file. When I trigger the error, the error is in the file mpegstream.cpp in the function MPEGstream::copy_byte(), in the final statement - return(*data++); The error is an attempt to dereference a null pointer. The Microsoft Development Environment reports the following: Unhandled exception at 0x01741242 (smpeg.dll) in TestApplication.exe: 0xC0000005: Access violation reading location 0x00000000. SDL 1.2.13 SDL_mixer 1.2.8 SMPEG 0.4.5 MSWindows 2000 Professional Service Pack 4 Microsoft Development Environment 2003 7.1.3088 We've fixed a bunch of crash bugs lately, can you check out this snapshot? http://www.libsdl.org/tmp/SDL_mixer.zip Thanks! I'm inclined to think this is an SMPEG bug and not an SDL_mixer bug. This is what Valgrind finds in playmus for a random MP3 that is otherwise playing fine with SDL_mixer... (SMPEG predates Valgrind, and hasn't received much attention since.) Opened audio at 22050 Hz 16 bit stereo (LE), 4096 bytes audio buffer ==31631== Conditional jump or move depends on uninitialised value(s) ==31631== at 0x6FCE96C: MPEGaudio::Stop() (MPEGaudio.cpp:205) ==31631== by 0x6FCEA89: MPEGaudio::Rewind() (MPEGaudio.cpp:219) ==31631== by 0x6FE0C66: MPEGaudio::initialize() (mpegtoraw.cpp:128) ==31631== by 0x6FCEE28: MPEGaudio::MPEGaudio(MPEGstream*, bool) (MPEGaudio.cpp:33) ==31631== by 0x6FC857D: MPEG::parse_stream_list() (MPEG.cpp:492) ==31631== by 0x6FC8EEA: MPEG::Init(SDL_RWops*, bool) (MPEG.cpp:106) ==31631== by 0x6FCE422: SMPEG_new (smpeg.cpp:84) ==31631== by 0x4E39534: Mix_LoadMUS (music.c:521) ==31631== by 0x401884: main (playmus.c:196) Playing /home/icculus/rodeo.mp3 ==31631== ==31631== Thread 3: ==31631== Conditional jump or move depends on uninitialised value(s) ==31631== at 0x6FDDBF6: MPEGaudio::layer3hybrid(int, int, float (*) [18], float (*) [32]) (mpeglayer3.cpp:1631) ==31631== by 0x6FDF547: MPEGaudio::extractlayer3() (mpeglayer3.cpp:1762) ==31631== by 0x6FE0934: MPEGaudio::run(int, double*) (mpegtoraw.cpp:314) ==31631== by 0x6FE0A2F: Decode_MPEGaudio(void*) (mpegtoraw.cpp:372) ==31631== by 0x5088816: SDL_RunThread (SDL_thread.c:204) ==31631== by 0x50D07D8: RunThread (SDL_systhread.c:47) ==31631== by 0x5E373B9: start_thread (in /lib/libpthread-2.9.so) ==31631== by 0x6131FCC: clone (in /lib/libc-2.9.so) ==31631== ==31631== Conditional jump or move depends on uninitialised value(s) ==31631== at 0x6FDDBF6: MPEGaudio::layer3hybrid(int, int, float (*) [18], float (*) [32]) (mpeglayer3.cpp:1631) ==31631== by 0x6FDF746: MPEGaudio::extractlayer3() (mpeglayer3.cpp:1766) ==31631== by 0x6FE0934: MPEGaudio::run(int, double*) (mpegtoraw.cpp:314) ==31631== by 0x6FE0A2F: Decode_MPEGaudio(void*) (mpegtoraw.cpp:372) ==31631== by 0x5088816: SDL_RunThread (SDL_thread.c:204) ==31631== by 0x50D07D8: RunThread (SDL_systhread.c:47) ==31631== by 0x5E373B9: start_thread (in /lib/libpthread-2.9.so) ==31631== by 0x6131FCC: clone (in /lib/libc-2.9.so) --ryan. svn revision #386 in smpeg's repository fixes the valgrind issues mentioned here, but I can't say if they cause this bug (however, one of them is an uninitialized variable being checked when starting playback of a new MP3). This is as far as I can go with this bug. --ryan. Can you retest with the latest code from subversion? Thanks! (And by quick and dirty fix, bad organization of needed headers in the project). (Sorry about the above comment - browser decided to (unknowingly) move me to this bug while commenting on a different bug) Waiting for several years on this one. :) |