flac dev - Sep 2004 - Re: 0.9 problems

Christian Weisgerber <naddy@mips.inka.de> wrote:
> #0  0x1600692a8 in FLAC__fixed_compute_best_predictor (data=0x11fc, 
>     data_len=1611182472, residual_bits_per_sample=0x0) at fixed.c:84
PS:  I can't make any sense out of the core file.  Various function
arguments are clearly bogus, but I'm unable to find a connection
between the source values in the local variables of the parent
function and the arguments passed.

-- 
Christian "naddy" Weisgerber                         
naddy@mips.inka.de

Matt Zimmerman <mdz@debian.org> wrote:
> 0.9.  As I said, I was using an 8-bit sample,
Ah, that didn't quite register with me.  I'm using a CD-style
44.1kHz/stereo/16-bit test file.
> to avoid dealing with endian issues in the file format.  I don't
> know whether any of those exist or not.
I don't think so.  0.9 works fine on i386 (little) and sparc (big),
and flac's output is identical on both architectures.  FWIW, alpha
is little endian.

-- 
Christian "naddy" Weisgerber                         
naddy@mips.inka.de

Matt Zimmerman <mdz@debian.org> wrote:
> Aha.  In FLAC__fixed_restore_signal, the index variable 'i' is
declared
> unsigned, then used like so: [...] With the following trivial patch
applied,
> everything works on Alpha, at least with my test sample.
Against 0.9 or CVS?  While this clearly fixes a bug, 0.9 still dies
for me.

#0  0x1600692a8 in FLAC__fixed_compute_best_predictor (data=0x11fc, 
    data_len=1611182472, residual_bits_per_sample=0x0) at fixed.c:84
84              residual_bits_per_sample[0] = (real)((data_len > 0) ?
log(M_LN2 * (real)total_error_0  / (real) data_len) / M_LN2 : 0.0);

(gdb) bt
#0  0x1600692a8 in FLAC__fixed_compute_best_predictor (data=0x11fc, 
    data_len=1611182472, residual_bits_per_sample=0x0) at fixed.c:84
#1  0x160064808 in encoder_process_subframe_ (encoder=0x11ffb86f, 
    max_partition_order=301971032, verbatim_only=0, frame_header=0xc, 
    subframe_bps=1610859008, integer_signal=0x1c3ffa043, real_signalCannot
access memory at address 0x11ffd458.
) at encoder.c:881
#2  0x160063d08 in encoder_process_subframes_ (encoder=0x1202c0000, 
    is_last_frame=0) at encoder.c:727
#3  0x1600634c0 in encoder_process_frame_ (encoder=0x160062fb4, 
    is_last_frame=301971567) at encoder.c:595
#4  0x160062fb4 in FLAC__encoder_process (encoder=0x7fffffff8000, 
    buf=0x1200246c0, samples=8) at encoder.c:523
#5  0x12000591c in encode_wav (infile=0x4 <Address 0x4 out of bounds>, 
    outfile=0x8 <Address 0x8 out of bounds>, verbose=4608, skip=0,
verify=0,
    lax=0, do_mid_side=301971559, loose_mid_side=301971572, 
    do_exhaustive_model_search=0, do_qlp_coeff_prec_search=301971585, 
    rice_optimization_level=301971606, max_lpc_order=301971624, 
    blocksize=301971644, qlp_coeff_precision=301971665, padding=301971695)
    at encode.c:280
#6  0x120009de0 in main (argc=301971695, argv=0x11ffb8ff) at main.c:293

-- 
Christian "naddy" Weisgerber                         
naddy@mips.inka.de

On Sat, May 19, 2001 at 02:10:15PM +0000, Christian Weisgerber wrote:
> Matt Zimmerman <mdz@debian.org> wrote:
> 
> > Aha.  In FLAC__fixed_restore_signal, the index variable 'i' is
declared
> > unsigned, then used like so: [...] With the following trivial patch
applied,
> > everything works on Alpha, at least with my test sample.
> 
> Against 0.9 or CVS?  While this clearly fixes a bug, 0.9 still dies
> for me.
0.9.  As I said, I was using an 8-bit sample, to avoid dealing with endian
issues in the file format.  I don't know whether any of those exist or not.
I'll take a look today if I have some time.

-- 
 - mdz