[FATE] atrac3 on opensolaris

[Vitor Sessak]

On 08/03/2010 07:36 PM, Måns Rullgård wrote:
> Michael Kostylev<michael.kostylev at gmail.com>  writes:
>
>> tiny_psnr shows not the same numbers as on FATE, however...
>>
>> --- fate-suite/atrac3/mc_sich_at3_066_small.dump
>> +++ x86_32-opensolaris-gcc-3.3.5/mc_sich_at3_066_small.dump
>> -0105410 0000 0000 0000 0000 0000 0000 0000 0000
>> +0105410 8100 08b4 0000 0000 0003 0000 0000 0000
>>
>> --- fate-suite/atrac3/mc_sich_at3_105_small.dump
>> +++ x86_32-opensolaris-gcc-3.3.5/mc_sich_at3_105_small.dump
>> -00a5910 0000 0000 0000 0000 0000 0000 0000 0000
>> +00a5910 7c00 08b4 0000 0000 0003 0000 0000 0000
>>
>> --- fate-suite/atrac3/mc_sich_at3_066_small.dump
>> +++ x86_64-opensolaris-gcc-4.4.1/mc_sich_at3_066_small.dump
>> -0106a70 0000 0000 0000 0000 0000 0000 0000 0000
>> -0106a80 0000 0000 0000 0000 0000 0000 0000 0000
>> +0106a70 3680 010d 0000 0000 0000 0000 0000 0000
>> +0106a80 0003 0000 0000 0000 0000 0000 0000 0000
>>
>> --- fate-suite/atrac3/mc_sich_at3_105_small.dump
>> +++ x86_64-opensolaris-gcc-4.4.1/mc_sich_at3_105_small.dump
>> -00a6df0 0000 0000 0000 0000 0000 0000 0000 0000
>> -00a6e00 0000 0000 0000 0000 0000 0000 0000 0000
>> +00a6df0 3300 010d 0000 0000 0000 0000 0000 0000
>> +00a6e00 0003 0000 0000 0000 0000 0000 0000 0000
>>
>> --- fate-suite/atrac3/mc_sich_at3_132_small.dump
>> +++ x86_64-opensolaris-gcc-4.4.1/mc_sich_at3_132_small.dump
>> -0084270 0000 0000 0000 0000 0000 0000 0000 0000
>> -0084280 0000 0000 0000 0000 0000 0000 0000 0000
>> +0084270 3e40 010d 0000 0000 0000 0000 0000 0000
>> +0084280 0003 0000 0000 0000 0000 0000 0000 0000
>
> Any ideas what might be causing it?

Yes, it depends on uninitialized memory. To reproduce it on a linux box:

vitor at vitor:~$ make fate-atrac3-1 TARGET_EXEC='valgrind 
--leak-check=full --error-exitcode=1 --malloc-fill=0x4f 
--suppressions=/home/vitor/ffmpeg/fate/sup.txt'
TEST    atrac3-1
stddev: 7849.96 PSNR: 18.43 MAXDIFF:20303 bytes:  1256960/  1256960

Michael, I suggest you to change the "--malloc-fill=0xff" in the 
valgrind box to "--malloc-fill=0x40" or something else (since -1  == 
0xff is very close to 0).

-Vitor