Vorbis dev - Jun 2000 - bug in glibc 2.1.2 and older

This is cropping up more than I expected.  Apparently, many distributions are
still shipping their latest versions with the broken glibcs...

Recently I decided that a specific glibc bug (that causes mangled audio or
crashes) that I found nearly a year ago (and has been fixed for as long) had
probably become scarce enough to risk removing the '-D__NO_MATH_INLINES'
define
from the build.  Math inlines help decode performance by using direct i387
assembly for exp() rather than a function call.

I was wrong.  It seems that glibc 2.1.2 and older is still alive and well.

Glibc 2.1.3 is required for libvorbis to build correctly.  Older versions of
glibc contain a bug in the hand-rolled inline assembly for math functions;
specifically, they interfere with GCC's FPU stack allocation and result in
stack overflows.

If you're curious about your glibc 2.1, look at
/usr/include/bit/mathinline.h and search for 'log10'.  The correct line
should read:

__inline_mathop_decl (log10, "fldlg2; fxch; fyl2x", "0"
(__x) : "st(1)")

If your version is missing the "st(1)" at the end, YOU WILL NOT BE
ABLE TO BUILD A WORKING LIBVORBIS.  Not only that, but anything you've ever
built on your machine that uses rint(), log(), log10(), exp(), etc, stands a
good chance of being broken.  Upgrading the libc (*and* the headers) and
rebuilding affected packages is the only way to eliminate the problem.

(Note that log10 is not the only affected function, it's just the easiest to
check.)

If replacing libc is not an option, all C modules should be built with
_D__NO_MATH_INLINES  This will result in a performance sacrifice, but will
produce correct binaries.

Monty

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/

> If replacing libc is not an option, all C modules should be built with
> _D__NO_MATH_INLINES  This will result in a performance sacrifice, but will
> produce correct binaries.
That should have read:
-D__NO_MATH_INLINES

Monty

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/

On Sat, 24 Jun 2000, Monty wrote:
> I was wrong.  It seems that glibc 2.1.2 and older is still alive and well.
It's worse than that:  www.gnu.org still (at least as of a couple of days
ago) points to 2.1.2 as being the latest and greatest.
> If replacing libc is not an option, all C modules should be built with
> _D__NO_MATH_INLINES This will result in a performance sacrifice, but
> will produce correct binaries.
Compiling with optimization level 1 (-O or -O1) also apparently works (at
least it's worked for my linux-intel system) without the huge (~36%)
performance hit.  For distribution or serious testing, however, I'd play
it safe for now and kill the inlines completely.

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/

On Sat, 24 Jun 2000, R.L. Horn wrote:
> ...For distribution or serious testing, however, I'd play
> it safe for now and kill the inlines completely.
I missed the beginning of this thread (I'm using 2.1.3), but why not just
have vorbis spit out an error on broken glibc's?

It can't be too hard to come up with a simple test to determine
correctness, can it? If the test fails, refuse to run and point people to
ftp.gnu.org.

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

> On Sat, 24 Jun 2000, Monty wrote:
> 
> > I was wrong.  It seems that glibc 2.1.2 and older is still alive and
well.
> 
> It's worse than that:  www.gnu.org still (at least as of a couple of
days
> ago) points to 2.1.2 as being the latest and greatest.
My.
> > If replacing libc is not an option, all C modules should be built with
> > _D__NO_MATH_INLINES This will result in a performance sacrifice, but
> > will produce correct binaries.
> 
> Compiling with optimization level 1 (-O or -O1) also apparently works (at
> least it's worked for my linux-intel system) without the huge (~36%)
> performance hit.
Actually, if a change in optimization causes different FPU scheduling, it may 
*appear* that the bug is fixed, when in fact it's still a ticking bomb (or
may
go off elsewhere).

For example, one of the early frustrations in tracking this bug last year was 
that adding a printf to watch the results go wrong will suddently make it all 
work (because the printf forces a float store to memory, reducing load on the 
stack).
>  For distribution or serious testing, however, I'd play
> it safe for now and kill the inlines completely.
Most likely a good idea.  Greg Olszewski (Hey Greg!  Great to see you on the
list!  Where are you hanging out to do your remote hacking these days?) has
already submitted an autoconf patch to hack a check in for this.  We can also
always build binaries for distribution on a system with a known, good glibc
(like Debian Woody).

Monty

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.