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: