On Sat, May 19, 2001 at 12:55:08AM -0400, Matt Zimmerman wrote:> On Sat, May 19, 2001 at 02:05:14AM +0000, Christian Weisgerber wrote: > > > Problems in FLAC 0.9: > > > > - On alpha, flac immediately dumps core for both encoding and > > decoding (FreeBSD/alpha). > > I have reproduced this on Debian/alpha as well. I will spend some time > debugging it tonight.I am doing my testing with an 8-bit mono sample, so that should hopefully rule out any endianness issues related to the audio data itself, and with all objects compiled using -g -O0 -DDEBUG -DFLAC_OVERFLOW_DETECT. Here is the stack trace for the crash when encoding: #0 0x200000e7304 in FLAC__fixed_compute_residual (data=0x1202b9c54, data_len=4607, order=1, residual=0x1202e6cc0) at fixed.c:165 #1 0x200000e1f44 in encoder_evaluate_fixed_subframe_ (signal=0x1202b9c50, residual=0x1202e6cc0, abs_residual=0x1202fd510, blocksize=4608, subframe_bps=8, order=1, rice_parameter=1, max_partition_order=4, subframe=0x200002aa2b0) at encoder.c:1028 #2 0x200000e1764 in encoder_process_subframe_ (encoder=0x1202b9bf0, max_partition_order=4, verbatim_only=0, frame_header=0x11ffff850, subframe_bps=8, integer_signal=0x1202b9c50, real_signal=0x1202be460, subframe=0x2000050b940, residual=0x2000028a0e0, best_subframe=0x2000050b9e0, best_bits=0x2000050ba08) at encoder.c:917 #3 0x200000e08d4 in encoder_process_subframes_ (encoder=0x1202b9bf0, is_last_frame=0) at encoder.c:727 #4 0x200000dffb4 in encoder_process_frame_ (encoder=0x1202b9bf0, is_last_frame=0) at encoder.c:595 #5 0x200000dfa14 in FLAC__encoder_process (encoder=0x1202b9bf0, buf=0x1202b96d8, samples=2048) at encoder.c:523 #6 0x120005d08 in encode_wav (infile=0x11ffffe26 "/home/mdz/english.wav", outfile=0x11ffffe3c "/home/mdz/english.flac", verbose=1, skip=0, verify=0, lax=0, do_mid_side=1, loose_mid_side=0, do_exhaustive_model_search=0, do_qlp_coeff_prec_search=0, rice_optimization_level=4, max_lpc_order=8, blocksize=4608, qlp_coeff_precision=0, padding=0) at encode.c:280 #7 0x12000a208 in main (argc=3, argv=0x11ffffc38) at main.c:293 and when decoding: #0 0x200000e7830 in FLAC__fixed_restore_signal (residual=0x1202ce480, data_len=4606, order=2, data=0x1202c9c78) at fixed.c:209 #1 0x200000ef25c in stream_decoder_read_subframe_fixed_ (decoder=0x1202b9c30, channel=0, bps=8, order=2) at stream_decoder.c:1158 #2 0x200000eeb34 in stream_decoder_read_subframe_ (decoder=0x1202b9c30, channel=0, bps=8) at stream_decoder.c:1069 #3 0x200000ed3a4 in stream_decoder_read_frame_ (decoder=0x1202b9c30, got_a_frame=0x11ffff9e8) at stream_decoder.c:673 #4 0x200000eb810 in FLAC__stream_decoder_process_whole_stream ( decoder=0x1202b9c30) at stream_decoder.c:240 #5 0x200000e5434 in FLAC__file_decoder_process_whole_file ( decoder=0x1202b9990) at file_decoder.c:181 #6 0x1200030cc in decode_wav (infile=0x11ffffe25 "/home/mdz/english.flac", outfile=0x11ffffe3c "/home/mdz/english2.wav", analysis_mode=0, aopts={ do_residual_text = 0, do_residual_gnuplot = 0}, verbose=1, skip=0) at decode.c:119 #7 0x12000a098 in main (argc=4, argv=0x11ffffc28) at main.c:288 It's not obvious at first glance where the fault is being triggered; residual and data both appear valid. -- - mdz
On Sat, May 19, 2001 at 04:11:02AM -0400, Matt Zimmerman wrote:> For some reason, gdb doesn't notice this when I ask it to evaluate data[i-1] > and data[i-2]. The encoding problem is the same thing, in > FLAC__fixed_compute_residual. With the following trivial patch applied, > everything works on Alpha, at least with my test sample. I don't know how > this managed to work before on i386.As further data points, with the patch applied, everything seems to work OK on SPARC and ARM as well. -- - mdz
On Sat, May 19, 2001 at 01:37:13AM -0400, Matt Zimmerman wrote:> It's not obvious at first glance where the fault is being triggered; residual > and data both appear valid.Aha. In FLAC__fixed_restore_signal, the index variable 'i' is declared unsigned, then used like so: for(i = 0; i < data_len; i++) { /* == residual[i] + 2*data[i-1] - data[i-2] */ data[i] = residual[i] + (data[i-1]<<1) - data[i- 2]; } For some reason, gdb doesn't notice this when I ask it to evaluate data[i-1] and data[i-2]. The encoding problem is the same thing, in FLAC__fixed_compute_residual. With the following trivial patch applied, everything works on Alpha, at least with my test sample. I don't know how this managed to work before on i386. --- fixed.c.orig Sat May 19 03:08:36 2001 +++ fixed.c Sat May 19 03:08:54 2001 @@ -152,7 +152,7 @@ void FLAC__fixed_compute_residual(const int32 data[], unsigned data_len, unsign ed order, int32 residual[]) { - unsigned i; + int i; switch(order) { case 0: @@ -190,7 +190,7 @@ void FLAC__fixed_restore_signal(const int32 residual[], unsigned data_len, unsi gned order, int32 data[]) { - unsigned i; + int i; switch(order) { case 0: -- - mdz
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