Mathew Hendry schrieb am Die, 15 Feb 2000:
> >
> > 0x805e2cc <calc_xmin+460>: fldl 0xfffffff0(%ebp)
>
> It loads a floating point value from memory into a floating point register.
> The value in memory is presumably invalid, so the CPU traps when it loads
> it.
So we have to figure out which variable it is. Then it would be interesting to
to see the memory usage in its neighbourhood. Either the calculation of the
variable itself goes wrong, or there is an index overflow by the calculation
of its neighbours.
here is the C-code, lame throws the SIGFPE at marked position:
int calc_xmin( FLOAT8 xr[576], III_psy_ratio *ratio,
gr_info *cod_info, III_psy_xmin *l3_xmin)
{
:
--> for ( sfb = 0; sfb < cod_info->sfb_lmax; sfb++ ){
start = scalefac_band.l[ sfb ];
end = scalefac_band.l[ sfb+1 ];
bw = end - start;
for (en0 = 0.0, l = start; l < end; l++ ) {
ener = xr[l] * xr[l];
en0 += ener;
}
en0 /= bw;
xmin = ratio->en.l[sfb];
if (xmin != 0.0)
xmin = en0 * ratio->thm.l[sfb] * masking_lower / xmin;
Robert
PS: yesterday I checked Mathew Hendry's quantize_xrqpow update into CVS
and fixed a problem with ms_convert: it was going wrong when the
source and destination array are identical, now ms_convert is
robust to handle this. It can convert in place now
today I got rid of some extra quantizations in VBR_iteration_loop
L earning
A bout
M p3
E ncoding
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
