corrupt data definition

corrupt data definition

am 22.12.2003 15:54:18 von Nat Ciesla

------=_NextPart_000_0000_01C3C869.2F0C4380
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

We have discovered what we think is a bug in mysql. We had a table called
artilces with a varchar(50) field called Title in it, and the following
query kept crashing the mysql service:

select max(ID) as ID2
FROM articles
WHERE Title=''

(where ID was an auto-incrementing INT as a primary key)

After much testing, and trying to replicate the error, we discovered the
following:

It did not matter if the ID field was an auto-increment or not.

If the ID field was no longer a key, it worked fine.

The query run without max or min worked fine.

The query run without WHERE worked fine.

And now, for the bizarre part: we renamed Title to Title2, and then back to
Title, and the problem disappeared completely, with the query running
perfectly in it's original form.

When the service crashed, the error logs did not show anything unusual. It
would restart without a problem.

Some details about our environment:
Windows 2000 server, also tested (and the problem still occured) on win2k
pro.
(I also did some research on deja.com and found references to this same
problem on Linux machines)

MySQL 4.0.15 (4.0.12 on win2k pro machine)



Conclusion: I think the definition for the Title field became corrupted
somehow, but it was such a small level of corruption that it only caused
problems when the index field (ID) was used with a special function, such as
MIN or MAX (on the references to this problem on linux machines, the
DISTINCT function was also mentioned, but we haven't tested it). I'm
guessing that the action of renaming the field completely rebuilt the
definition of the field in MySQL and therefore fixed whatever was corrupted.

Unfortunately, this error is very difficult to replicate, because we still
don't know how the field definition became corrupted in the first place.



Nat Ciesla
wisnet.com, LLC


------=_NextPart_000_0000_01C3C869.2F0C4380
Content-Type: text/plain; charset=us-ascii

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org
------=_NextPart_000_0000_01C3C869.2F0C4380--

Re: corrupt data definition

am 22.12.2003 17:41:19 von miguel solorzano

--=======7E046FF9=======
Content-Type: text/plain; x-avg-checked=avg-ok-6354386F; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

At 08:54 22/12/2003 -0600, Nat Ciesla wrote:
Hi,

>We have discovered what we think is a bug in mysql. We had a table called
>artilces with a varchar(50) field called Title in it, and the following
>query kept crashing the mysql service:
>
>select max(ID) as ID2
>FROM articles
>WHERE Title=3D''
>
>(where ID was an auto-incrementing INT as a primary key)

I tested with 4.0.17 and I wasn't able to repeat. Please
test this version and continuing the corrupt issue try
to create a repeatable test case, open a bug report
attaching the test case.



--=20
Regards,

For technical support contracts, visit https://order.mysql.com/
Are you MySQL certified?, http://www.mysql.com/certification/

Miguel Angel Sol=F3rzano
S=E3o Paulo - Brazil

--=======7E046FF9=======
Content-Type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-6354386F
Content-Disposition: inline


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.551 / Virus Database: 343 - Release Date: 11/12/2003


--=======7E046FF9=======
Content-Type: text/plain; charset=us-ascii

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org
--=======7E046FF9=======--

RE: corrupt data definition

am 22.12.2003 18:56:28 von Sinisa Milivojevic

Nat Ciesla writes:
> I have uploaded "articles.zip" to the folder you provided.
>
> I also tested it with MySQL 4.0.17 and the crash still occurs with this
> table.
>
> Thanks.
>
> Nat Ciesla
> wisnet.com, LLC

Hi!

Thank you so much for your bug report.

What you reported was truly a bug causing terrible crashes in the
current MySQL 4.0 (and higher) servers.

I have already suggested a patch for the bug fix, but it will have to
pass all our testing and approval phases.

A bug fix shall be soon commited to our BK repository.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information
about accessing the source trees is available at
http://www.mysql.com/doc/en/Installing_source_tree.html

Thanks again, a lot !!

--

Sincerely,

--
For technical support contracts, go to https://order.mysql.com/?ref=msmi
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB
/_/ /_/\_, /___/\___\_\___/ Fulltime Developer and Support Coordinator
<___/ www.mysql.com Larnaca, Cyprus


--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org