From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description of problem: Using built on my system timidity++ to convert mid file to wav I've got message from timidity++: ... Text: C14-P2-Rhythm Guit Text: C15-P3-Melody Text: C16-Drums Strange, I feel like allocating 197254 bytes. This must be a bug. ... I have investigated it and found that some function requested enormous amount of memory, here is stack backtrace: #0 0x40000000000337c0 in safe_malloc (count=9223389624746050182) at common.c:465 #1 0x4000000000049430 in load_gus_instrument (name=0x6000000000140d80 "/usr/share/timidity/instruments/acpiano", bank=0x600000000003ab60, dr=0, prog=0, infomsg=0x80000fffffffac50 "Tonebank 0 0") at instrum.c:606 #2 0x400000000004cbe0 in load_instrument (dr=0, b=0, prog=0) at instrum.c:808 #3 0x400000000004dd10 in fill_bank (dr=0, b=0, rc=0x80000fffffffb0b0) at instrum.c:874 #4 0x400000000004e3e0 in load_missing_instruments (rc=0x80000fffffffb0b0) at instrum.c:899 #5 0x40000000000c98f0 in play_midi_load_file (fn=0x6000000000140d40 "canyon.mid", event=0x80000fffffffb290, nsamples=0x80000fffffffb298) at playmidi.c:4445 #6 0x40000000000ca150 in play_midi_file (fn=0x6000000000140d40 "canyon.mid") at playmidi.c:4500 #7 0x40000000000caea0 in dumb_pass_playing_list (number_of_files=1, list_of_files=0x6000000000140d20) at playmidi.c:4560 #8 0x4000000000169e10 in timidity_play_main (nfiles=1, files=0x6000000000140d20) at timidity.c:3167 #9 0x400000000016b330 in main (argc=4, argv=0x80000fffffffb6c8) at timidity.c:3416 I've investigated further and found that sp->data_length (main summand of amount of memory requested) contain bad number: -4294770044. The reason is that sp->data_length has int32 type and its value is red thru URL::url_read routine as 4 byte length value. But, here is root!, in timidity.h int32 is declared as long. This is absolutely incorrect! Type long on IA64 is 8 bytes width, not 4 as on IA32, but you are handling it as it would have only 32 bits. And you use 64 bit width type in many places wrongly asssuming that it is 32 bit width. So elder 32 bites of any "int32" variable still uninitialed when you read it byte by byte from extern location. You are just lucky that standart gcc compiled version looks stabile, in reality timidity stability depends on hit or miss. Workaround is to take into account that type long is 64 bit width in IA64 and modify timidity.h to cast int32 as int (and accordingly uint32). With this timidity++ becomes more stabile and at least does what I needed from it. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. I don't know how easy this bug is reproducible with standart gcc 2.96, but it is reproducible every time with Intel C/C++ compiler. 2. Just compile the sources and try to convert canyon.mid i've attached with command line: > timidity canyon.mid -a -Ow Actual Results: received: Playing canyon.mid MIDI file: canyon.mid Format: 0 Tracks: 1 Divisions: 480 Text: C1-P91 Synth Pads Text: C2-P28 Rhythm Guit. Text: C3-P1 Acous. Piano Text: C4-P34 Elec. Bass Text: C5-P30 Dist. Guitar Text: C6-P10 Glock. Text: C10-Drums Text: B) 1991 Text: Passport Designs, Inc. Text: Produced By The Text: Music Data Company Text: C13-P86-Synth Text: C14-P2-Rhythm Guit Text: C15-P3-Melody Text: C16-Drums Strange, I feel like allocating 197254 bytes. This must be a bug. Expected Results: Succesfull conversion to wav file. Additional info:
Created attachment 82064 [details] mid file which helps to show bug described
Fixed in newer versions.