Thread: red hat/mysql fiasco

red hat/mysql fiasco

From
Alessio Bragadini
Date:
We should be nice and professional on holiday season but sorry, I
couldn't help myself: at
<http://freshmeat.net/news/2000/12/21/977385850.html>
we can read

"The MySQL packages shipped with Red Hat Linux 7 contained buggy
assembler code. When compiled with optimization
   enabled, this code caused the database server to return bad results.
Also, a case where you can crash the database by a
   specific, valid query has been fixed. Updated packages are available
from updates.redhat.com. "

Just to make it a little in-topic I would like to 1) thanks Core team
and all hackers and packagers for never putting us into such trouble and
2) issue a vehement cry - PLEASE assure things will stay this way, and
we can reasonably trust every release.

I do believe 2001 will be the big year for PostgreSql.

P.S. RedHat chose to ship a beta version of MySql with RH7, so I believe
that's more their fault than MySql people - but indeed there must be
also a serious flaw in source code.

--
Alessio F. Bragadini            alessio@albourne.com
APL Financial Services          http://village.albourne.com
Nicosia, Cyprus                 phone: +357-2-755750

"It is more complicated than you think"
                -- The Eighth Networking Truth from RFC 1925

Re: red hat/mysql fiasco

From
Mike Castle
Date:
On Thu, Dec 21, 2000 at 11:46:33AM +0200, Alessio Bragadini wrote:
> "The MySQL packages shipped with Red Hat Linux 7 contained buggy
> assembler code. When compiled with optimization
>    enabled, this code caused the database server to return bad results.

> P.S. RedHat chose to ship a beta version of MySql with RH7, so I believe
> that's more their fault than MySql people - but indeed there must be
> also a serious flaw in source code.


I would tend to think this would be a bug in gcc.

For instance, gcc (2.95.2 at least) produces buggy code involving "long
long int" under certain circumstances.  Sure hope PostgreSQL doesn't use
"long long int" anywhere.  Or someone might say that's a serious flaw in
the source code that gcc generated buggy assembler code.

[Actually, the beta version of the gcc compiler that RH is now shipping
with doesn't have this particular long long bug, but the latest official
release of gcc does.]

mrc
--
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: red hat/mysql fiasco

From
"Mike Sears"
Date:
> On Thu, Dec 21, 2000 at 11:46:33AM +0200, Alessio Bragadini wrote:
> > "The MySQL packages shipped with Red Hat Linux 7 contained buggy
> > assembler code. When compiled with optimization
> >    enabled, this code caused the database server to return bad results.
>
> > P.S. RedHat chose to ship a beta version of MySql with RH7, so I believe
> > that's more their fault than MySql people - but indeed there must be
> > also a serious flaw in source code.
>
>
> I would tend to think this would be a bug in gcc.
>
> For instance, gcc (2.95.2 at least) produces buggy code involving "long
> long int" under certain circumstances.  Sure hope PostgreSQL doesn't use
> "long long int" anywhere.  Or someone might say that's a serious flaw in
> the source code that gcc generated buggy assembler code.
>
> [Actually, the beta version of the gcc compiler that RH is now shipping
> with doesn't have this particular long long bug, but the latest official
> release of gcc does.]
>
> mrc

actually I had that problem w/ assembler errors in my defualt install of
redhat7. after fixing gcc that dissapeard.

its definatly a bug in the version of gcc that redhat stupidly shiped  but
its not totaly unfixable.

Mike


Re: red hat/mysql fiasco

From
Mike Castle
Date:
On Thu, Dec 21, 2000 at 11:23:32AM -0500, Mike Sears wrote:
> > [Actually, the beta version of the gcc compiler that RH is now shipping
> > with doesn't have this particular long long bug, but the latest official
> > release of gcc does.]
>
> actually I had that problem w/ assembler errors in my defualt install of
> redhat7. after fixing gcc that dissapeard.
>
> its definatly a bug in the version of gcc that redhat stupidly shiped  but
> its not totaly unfixable.

Odd.  I thought at least the long long bug was fixed in RH7's gcc "2.96"
(may be other bugs, true, but I thought long long wasn't one of them).

mrc
--
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: red hat/mysql fiasco

From
Alvaro Herrera
Date:
On Thu, 21 Dec 2000, Alessio Bragadini wrote:

> "The MySQL packages shipped with Red Hat Linux 7 contained buggy
> assembler code. When compiled with optimization enabled, this code
> caused the database server to return bad results.  Also, a case where
> you can crash the database by a specific, valid query has been fixed.
> Updated packages are available from updates.redhat.com. "

Mandrake packages for Postgresql are also flawed, in 7.2 at least. When
you cast some strings as timestamps, you can get weird values ("0:10:00"
-> "0:09:60"). It's also a compiler problem.

Fortunately, Postgresql-packaged RPMs for Mandrake don't have this
"feature".

--
Alvaro Herrera (<alvherre[@]protecne.cl>)


Re: red hat/mysql fiasco

From
Lamar Owen
Date:
Alvaro Herrera wrote:
> On Thu, 21 Dec 2000, Alessio Bragadini wrote:
> Mandrake packages for Postgresql are also flawed, in 7.2 at least. When
> you cast some strings as timestamps, you can get weird values ("0:10:00"
> -> "0:09:60"). It's also a compiler problem.

> Fortunately, Postgresql-packaged RPMs for Mandrake don't have this
> "feature".

Could be a bad -O setting.  The way RPM works in the build process
(which is, IMHO, not very good) means that typically the spec file that
controls the build sets the compilation options to include potentially
faulty combinations with certain programs.

Mandrake is known for aggressive -O settings.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Re: red hat/mysql fiasco

From
teg@redhat.com (Trond Eivind Glomsrød)
Date:
Mike Castle <dalgoda@ix.netcom.com> writes:

> On Thu, Dec 21, 2000 at 11:46:33AM +0200, Alessio Bragadini wrote:
> > "The MySQL packages shipped with Red Hat Linux 7 contained buggy
> > assembler code. When compiled with optimization
> >    enabled, this code caused the database server to return bad results.
 >
> > P.S. RedHat chose to ship a beta version of MySql with RH7, so I believe
> > that's more their fault than MySql people - but indeed there must be
> > also a serious flaw in source code.
>
>
> I would tend to think this would be a bug in gcc.

No. That was our first thought as well. However, during the search for
the bug we found that the bug was in their assembly code(aliasing). The patch
was submitted by us. We also found a bug in their SPARC assembly,
where they used a reserved register.

--
Trond Eivind Glomsrød
Red Hat, Inc.

Re: red hat/mysql fiasco

From
teg@redhat.com (Trond Eivind Glomsrød)
Date:
Alessio Bragadini <alessio@albourne.com> writes:

> P.S. RedHat chose to ship a beta version of MySql with RH7, so I believe
> that's more their fault than MySql people - but indeed there must be
> also a serious flaw in source code.

We shipped the one we could ship - the latter ones are the only one
with a free license.

MySQL is not the database we recommend FTTB (that is PostgreSQL, and
Oracle for higher end needs) and it is not a choice from the main
menu. If you choose packages individually, you can MySQL but the "SQL
Server" installation alternative gives you PostgreSQL.
--
Trond Eivind Glomsrød
Red Hat, Inc.