Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crash in timidity code #7

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 0 comments
Closed

crash in timidity code #7

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: unspecified
Reported for operating system, platform: OpenBSD, x86

Comments on the original bug report:

On 2006-01-31 02:42:07 +0000, Jolan Luff wrote:

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

On 2006-01-31 02:43:38 +0000, Jolan Luff wrote:

Created attachment 56
test file

On 2006-01-31 02:51:14 +0000, Jolan Luff wrote:

BTW, if I use timidity++ 2.13.2 standalone the file plays OK.

On 2006-05-01 06:48:12 +0000, Sam Lantinga wrote:

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)

On 2006-05-01 11:49:47 +0000, Jolan Luff wrote:

here you go:

http://protection.cx/~jolan/tmp/timiditystuff.tar.gz

On 2006-05-07 13:30:07 +0000, Sam Lantinga wrote:

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

On 2006-05-08 11:31:14 +0000, Jolan Luff wrote:

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

On 2006-05-09 04:16:31 +0000, Sam Lantinga wrote:

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.

On 2006-06-25 16:16:18 +0000, Ryan C. Gordon wrote:

Can't reproduce here, too, and valgrind doesn't complain either.

--ryan.

On 2006-10-17 13:58:34 +0000, Mike Swanson wrote:

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)

On 2006-10-17 14:09:44 +0000, Jolan Luff wrote:

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.

On 2007-07-14 15:10:26 +0000, Sam Lantinga wrote:

Okay, I was finally able to reproduce this on OpenBSD 4.1. I'm looking into it now.

On 2007-07-14 16:47:34 +0000, Sam Lantinga wrote:

This is fixed with subversion revision 3267.

Hooray for paranoid operating systems! This was a long standing memory corruption problem in the timidity code. :)

On 2007-07-14 18:07:36 +0000, Jolan Luff wrote:

Great, thank you very much!

On 2007-07-14 18:53:03 +0000, Sam Lantinga wrote:

You're welcome! :)

On 2007-07-15 03:21:34 +0000, Ryan C. Gordon wrote:

Are we sending that Timidity patch upstream? I'm not sure who maintains Timidity at this point...

--ryan.

On 2007-07-15 07:08:44 +0000, Sam Lantinga wrote:

No, the version of timidity we use is no longer being maintained.

On 2007-07-15 08:04:23 +0000, Ryan C. Gordon wrote:

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.

On 2007-07-15 08:24:06 +0000, Sam Lantinga wrote:

Hah. SDL_mixer's fix is probably a little better since it doesn't distort the first sample.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant