Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 76728

Summary: Sources: 64 bit width type is used as int32 - causes fault in run-time
Product: [Retired] Red Hat Linux Reporter: Sysoltsev Slawa <vyatcheslav.sysoltsev>
Component: timidity++Assignee: Thomas Woerner <twoerner>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2   
Target Milestone: ---   
Target Release: ---   
Hardware: ia64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-04-21 15:29:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
mid file which helps to show bug described none

Description Sysoltsev Slawa 2002-10-25 15:41:25 UTC
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:

Comment 1 Sysoltsev Slawa 2002-10-25 15:44:12 UTC
Created attachment 82064 [details]
mid file which helps to show bug described

Comment 2 Thomas Woerner 2004-04-21 15:29:10 UTC
Fixed in newer versions.