We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 118 - crash in timidity code
Summary: crash in timidity code
Status: CLOSED FIXED
Alias: None
Product: SDL_mixer
Classification: Unclassified
Component: misc (show other bugs)
Version: unspecified
Hardware: x86 OpenBSD
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-31 02:42 UTC by Jolan Luff
Modified: 2007-07-15 08:24 UTC (History)
0 users

See Also:

Attachments
test file (30.43 KB, application/octet-stream)
2006-01-31 02:43 UTC, Jolan Luff 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jolan Luff 2006-01-31 02:42:07 UTC 
when playing a certain midi file, i always get a crash:

$ gdb playmus
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd3.9"...
(gdb) set args level2.mid
(gdb) run
Starting program: /usr/local/bin/playmus level2.mid
Opened audio at 22050 Hz 16 bit stereo, 4096 bytes audio buffer
Playing level2.mid

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 29597, thread 0x7ddd7000]
0x0be2ab93 in pre_resample (sp=0x7f52d200) at resample.c:723
723           v1 = *(vptr - 1);
(gdb) bt
#0  0x0be2ab93 in pre_resample (sp=0x7f52d200) at resample.c:723
#1  0x0be1de54 in load_instrument (name=0x81f61400 "gsdrum00/congalo", 
    font_type=0, percussion=1, panning=-1, amp=-1, cfg_tuning=0, 
    note_to_use=64, strip_loop=1, strip_envelope=1, strip_tail=-1, bank=0, 
    gm_num=192, sf_ix=0) at instrum.c:827
#2  0x0be1e2c3 in fill_bank (dr=1, b=0) at instrum.c:900
#3  0x0be1e5ba in load_missing_instruments () at instrum.c:990
#4  0x0be26ed4 in Timidity_Start (song=0x86df29e0) at playmidi.c:1729
#5  0x0be12bd0 in music_internal_play (music=0x81f615c0, position=0)
    at music.c:741
#6  0x0be12d93 in Mix_FadeInMusicPos (music=0x81f615c0, loops=0, ms=2000, 
    position=0) at music.c:811
#7  0x0be12ddc in Mix_FadeInMusic (music=0x81f615c0, loops=0, ms=2000)
    at music.c:818
#8  0x1c00137f in main (argc=2, argv=0xcfbe7810) at playmus.c:192
Comment 1 Jolan Luff 2006-01-31 02:43:38 UTC 
Created attachment 56 [details]
test file
Comment 2 Jolan Luff 2006-01-31 02:51:14 UTC 
BTW, if I use timidity++ 2.13.2 standalone the file plays OK.
Comment 3 Sam Lantinga 2006-05-01 06:48:12 UTC 
I don't have the same patch set as you, apparently.  Can you post a link to your timidity.cfg and your instrument set (including gsdrum00/congalo)
Comment 4 Jolan Luff 2006-05-01 11:49:47 UTC 
here you go:

http://protection.cx/~jolan/tmp/timiditystuff.tar.gz
Comment 5 Sam Lantinga 2006-05-07 13:30:07 UTC 
I can't reproduce this in the code from CVS, is it fixed?
http://www.libsdl.org/tmp/SDL_mixer-1.2.7.tar.gz
Comment 6 Jolan Luff 2006-05-08 11:31:14 UTC 
No, it crashes in the same exact place with the code from the 1.2.7 tarball:

Starting program: /usr/obj/ports/sdl-mixer-1.2.7/SDL_mixer-1.2.7/build/playmus ~/level2.mid
Opened audio at 22050 Hz 16 bit stereo (LE), 4096 bytes audio buffer
Playing /usr/home/jolan/level2.mid

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 32757, thread 0x7c586000]
0x1c034b33 in pre_resample (sp=0x80526200) at timidity/resample.c:723
723           v1 = *(vptr - 1);
(gdb) bt
#0  0x1c034b33 in pre_resample (sp=0x80526200) at timidity/resample.c:723
#1  0x1c030e51 in load_instrument (name=0x836f7400 "gsdrum00/congalo", 
    font_type=0, percussion=1, panning=-1, amp=-1, cfg_tuning=0, 
    note_to_use=64, strip_loop=1, strip_envelope=1, strip_tail=-1, bank=0, 
    gm_num=192, sf_ix=0) at timidity/instrum.c:834
#2  0x1c03128a in fill_bank (dr=1, b=0) at timidity/instrum.c:907
#3  0x1c031512 in load_missing_instruments () at timidity/instrum.c:997
#4  0x1c019950 in Timidity_Start (song=0x7f366a00) at timidity/playmidi.c:1754
#5  0x1c00614e in music_internal_play (music=0x836f7600, position=0)
    at music.c:768
#6  0x1c0062f1 in Mix_FadeInMusicPos (music=0x836f7600, loops=0, ms=2000, 
    position=0) at music.c:838
#7  0x1c00632a in Mix_FadeInMusic (music=0x836f7600, loops=0, ms=2000)
    at music.c:845
#8  0x1c002620 in main (argc=2, argv=0xcf7f326c) at playmus.c:203
Comment 7 Sam Lantinga 2006-05-09 04:16:31 UTC 
Could this be an optimizer bug?  I just tested this again, with ElectricFence to catch memory overwrites, and I confirmed that it's loading that instrument and resampling it with no problems here.  I'm running on Linux with gcc 4.0.
Comment 8 Ryan C. Gordon 2006-06-25 16:16:18 UTC 
Can't reproduce here, too, and valgrind doesn't complain either.

--ryan.
Comment 9 Mike Swanson 2006-10-17 13:58:34 UTC 
I'm having the same problem on OpenBSD 3.9. SDL_mixer always crashes on certain levels of DOOM (previously posted MIDI is exactly the same as E2M1). It happens on DOOM 2 MAP02 and Ultimate DOOM E2M1, at least; I haven't done extensive testing of all the levels, but I know that Ultimate E1 and E3 are completely okay (also meaning you can't reproduce with only the shareware IWAD). Happens in Chocolate Doom and PrBoom, at least (I'm not going to try all the source ports)
Comment 10 Jolan Luff 2006-10-17 14:09:44 UTC 
I don't think this is an optimizer bug since this happens on multiple OpenBSD architectures (amd64, arm, i386, powerpc).  It's my understanding that gcc optimizations are platform specific.

OpenBSD does have a rather zealous malloc which will crash even in the event of a reading one byte too much, maybe this is the problem?

I'd be willing to provide a login to an OpenBSD machine if needed.
Comment 11 Sam Lantinga 2007-07-14 15:10:26 UTC 
Okay, I was finally able to reproduce this on OpenBSD 4.1.  I'm looking into it now.
Comment 12 Sam Lantinga 2007-07-14 16:47:34 UTC 
This is fixed with subversion revision 3267.

Hooray for paranoid operating systems!  This was a long standing memory corruption problem in the timidity code. :)
Comment 13 Jolan Luff 2007-07-14 18:07:36 UTC 
Great, thank you very much!
Comment 14 Sam Lantinga 2007-07-14 18:53:03 UTC 
You're welcome! :)
Comment 15 Ryan C. Gordon 2007-07-15 03:21:34 UTC 
Are we sending that Timidity patch upstream? I'm not sure who maintains Timidity at this point...

--ryan.
Comment 16 Sam Lantinga 2007-07-15 07:08:44 UTC 
No, the version of timidity we use is no longer being maintained.
Comment 17 Ryan C. Gordon 2007-07-15 08:04:23 UTC 
Argh, I just went to apply this fix to the Timidity in SDL_sound and found this:

http://svn.icculus.org/SDL_sound/branches/stable-1.0/decoders/timidity/resample.c?r1=204&r2=259&p1=trunk/decoders/timidity/resample.c&p2=trunk/decoders/timidity/resample.c

      vptr = src + (ofs >> FRACTION_BITS);
          /*
           * Electric Fence to the rescue: Accessing *(vptr - 1) is not a
           * good thing to do when vptr <= src. (TiMidity++ has a similar
           * safe-guard here.)
           */
      v1 = (vptr > src) ? *(vptr - 1) : 0;



Apparently I fixed this exact bug about 5 years ago. I'm really sorry this got left open so long in Bugzilla (and that I never backported the fix to SDL_mixer in the first place).

Sorry about that.  :/

--ryan.
Comment 18 Sam Lantinga 2007-07-15 08:24:06 UTC 
Hah.  SDL_mixer's fix is probably a little better since it doesn't distort the first sample.