On Fri, Aug 16, 2002 at 11:14:01AM -0700, Josh Coalson wrote:> --- Josh Coalson <xflac@yahoo.com> wrote: > >... > > If anyone with a similar set up can read the comments in the > > following bug reports and do some investigation it would really > > help a lot. I would like to hear about setups that are working > > as much as ones that aren't. > > OK, someone with a Duron has uploaded some test files which > reproduce errors in the same spot, but sporadically, on Linux too. > His comments and files are here: > > http://sourceforge.net/tracker/index.php?func=detail&aid=595858&group_id=13478&atid=113478I am able to reproduce this on my system. I am of course using the same Debian packaged binary, and the test files from the bug tracker. It does not happen every time. Sometimes I can get the failure in a few tries, and sometimes I run several hundred iterations with no problems. processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) Processor stepping : 4 cpu MHz : 1394.099 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips : 2785.28 mizar:[/tmp] flac -4 -V *.wav flac 1.0.3, Copyright (C) 2000,2001,2002 Josh Coalson flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. Type `flac' for details. options: -P- -b 4608 -M -l 8 -q 0 -r 3,3 -R 0 -V iits1792.wav: Verify OK, wrote 11886 bytes, ratio=0.643 iits2430.wav: Verify OK, wrote 9274 bytes, ratio=0.502 iits2430.wav: ERROR: mismatch in decoded data, verify FAILED! Please submit a bug report to http://sourceforge.net/bugs/?func=addbug&group_id=13478 Make sure to include an email contact in the comment and/or use the "Monitor" feature to monitor the bug status. Absolute sample=3453, frame=0, channel=1, sample=3453, expected 325, got 69 iits2430.wav: ERROR during encoding, state = 15:FLAC__STREAM_ENCODER_FATAL_ERROR_WHILE_WRITING iits2430.wav: 200% complete, ratio=0.504 iits2430.wav: ERROR: verification decoder returned error 1:FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER Verify FAILED! (FLAC__VERIFY_FAILED_IN_FRAME) Do not trust iits2430.flac zsh: exit 1 flac -4 -V *.wav mizar:[/tmp] flac -4 -V *.wav -- - mdz
On Sat, Aug 17, 2002 at 08:03:53AM -0700, Josh Coalson wrote:> --- Matt Zimmerman <mdz@debian.org> wrote: > > > > I am able to reproduce this on my system. I am of course using the > > same > > Debian packaged binary, and the test files from the bug tracker. It > > does > > not happen every time. Sometimes I can get the failure in a few > > tries, and > > sometimes I run several hundred iterations with no problems. > > In wierd way this is almost a relief. :)Don't be too relieved...my system has also begun to exhibit other odd symptoms just recently. After many months of stability, I am experiencing random hangs. I ran a memtest86 yesterday, and the test turned up many errors. The errors seem to occur in many areas of memory, though, across both memory modules that I have installed. I am not overclocking or anything else questionable, though during the summer months my apartment has gotten rather warm due to lack of air conditioning.> These are the things I would suspect, in order: > > * 3DNOW code (configure --enable-3dnow, turned off by default, > but I'm not sure how the package was built) > * Other IA32 assembly code (on by default) > * gcc -march=? (AMD-specific optimizations?)The package is built to work on all i386+ systems, so 3dnow is disabled, and CFLAGS=-O2. The final command lines end up looking like this: /bin/sh ../../libtool --mode=compile gcc -DPACKAGE=\"flac\" -DVERSION=\"1.0.3\" -DHAVE_DLFCN_H=1 -DHAVE_GETOPT_LONG=1 -DFLAC__CPU_IA32=1 -DFLAC__ALIGN_MALLOC_DATA=1 -DFLAC__HAS_OGG=1 -DFLAC__HAS_NASM=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -I. -I. -I../.. -I./include -I../../include -O2 -O3 -DNDEBUG -fomit-frame-pointer -funroll-loops -finline-functions -Wall -W -Winline -DFLaC__INLINE=__inline__ -c bitbuffer.c And now that I notice it, your -O3 is overriding my -O2. :-/ I really want -O2, as this is recommended policy for Debian packages. I seem to recall that this worked correctly in earlier releases, but it looks like you've reorganized the CFLAGS stuff in configure.in since then. I'm running a test now with a binary built with --enable-debug --disable-asm-optimizations, and so far I have seen no failures after several hundred iterations.> * Pointer aliasing vs. gcc3 (I would think this would show up > on other architectures. I have not built with gcc3 yet. > The pointer aliasing rules are new to me; there is pointer > aliasing in flac and the plugins)The Debian packages are built with gcc version 2.95.4 20011002 (Debian prerelease), which has proven extremely robust and reliable (including building the Debian Linux kernels on i386). Some other Debian architectures use gcc 3.x by default, but not i386. -- - mdz
--- Matt Zimmerman <mdz@debian.org> wrote:> On Fri, Aug 16, 2002 at 11:14:01AM -0700, Josh Coalson wrote: > > > --- Josh Coalson <xflac@yahoo.com> wrote: > > >... > > > If anyone with a similar set up can read the comments in the > > > following bug reports and do some investigation it would really > > > help a lot. I would like to hear about setups that are working > > > as much as ones that aren't. > > > > OK, someone with a Duron has uploaded some test files which > > reproduce errors in the same spot, but sporadically, on Linux too. > > His comments and files are here: > > > > >http://sourceforge.net/tracker/index.php?func=detail&aid=595858&group_id=13478&atid=113478> > I am able to reproduce this on my system. I am of course using the > same > Debian packaged binary, and the test files from the bug tracker. It > does > not happen every time. Sometimes I can get the failure in a few > tries, and > sometimes I run several hundred iterations with no problems.In wierd way this is almost a relief. :) These are the things I would suspect, in order: * 3DNOW code (configure --enable-3dnow, turned off by default, but I'm not sure how the package was built) * Other IA32 assembly code (on by default) * gcc -march=? (AMD-specific optimizations?) * Pointer aliasing vs. gcc3 (I would think this would show up on other architectures. I have not built with gcc3 yet. The pointer aliasing rules are new to me; there is pointer aliasing in flac and the plugins) After that I'm not sure... Josh __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Josh Coalson wrote:> These are the things I would suspect, in order: > > * 3DNOW code (configure --enable-3dnow, turned off by default, > but I'm not sure how the package was built) > * Other IA32 assembly code (on by default) > * gcc -march=? (AMD-specific optimizations?) > * Pointer aliasing vs. gcc3 (I would think this would show up > on other architectures. I have not built with gcc3 yet. > The pointer aliasing rules are new to me; there is pointer > aliasing in flac and the plugins)I compiled from CVS using Makefile.lite today and I got exactly the same verification errors except iits2430.wav which didn't produce any error. I set the libFLAC Makefile options such that the compile command was: gcc -g -O0 -DDEBUG -DFLAC__OVERFLOW_DETECT -march=i386 -Wall -W -DVERSION=\"1.0.3\" -DFLAC__CPU_UNKNOWN -DFLAC__NO_NASM -DFLAC__ALIGN_MALLOC_DATA -I./include -I../../include Compiler is gcc 2.95.4 I will try running memtest86 as Matt did to see if that could be the problem. Thanks, Jon
Seemingly Similar Threads
- AMD debugging test files available
- [PATCH] Fix building with MSYS and MinGW(-w64); Improve Makefile.lite build system
- [PATCH] Makefile.lite: Fix building with MSYS and MinGW(-w64), Improvements
- 1.0 candidate checked in
- Desktop lag with CentOS7/Mate and high CPU usage