Bug #12066 Consistant Table Corruption on OS X (Got error 127 from storage engine)

Submitted: 20 Jul 2005 18:11 Modified: 20 Jul 2005 18:17
Reporter: Dan Tappin Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Server Severity:S2 (Serious)
Version:4.x OS:OX 10.x
Assigned to: CPU Architecture:Any

[20 Jul 2005 18:11] Dan Tappin
Description:
I have been experiencing consistent, repeatable table corruption on OS X with MySQL 4.x.  I have several MySQL 4.x and PHP4/5 / Apache installs where I have the typical PHP accessing MySQL for several websites.  The typical pattern is that a row is inserted into a table (MyISAM), the table becomes corrupted and then queries fail with 'Got error 127 from storage engine' reported from MySQL.

I have been running OS X 10.x, MySQL and PHP servers for the past 3-4 years.  My first build was MySQL 3.x on OS 10.2.  I NEVER once saw this issue on MySQL 3.x.  I saw this soon after my 4.x upgrade.  I wish I had more background to indicate which rev initiated he issue.  I have deleted the stock Apple MySQL install that comes with OS X and installed the package installers from scratch and also ensuring that I have referenced the correct paths to the new software.

How to repeat:
I have built multiple servers on OS X 10.2, 10.3 Server and 10.4 Server.  Each with various builds of MySQL 4.1.x and various hardware configurations (single drive and RAID etc).

I feel that I have ruled out a hardware issue and the repeatability issue make me think it it some kind of OS X <-> MySQL issue.

The occurrence is random... I can't seem to find a common trigger.  My sites will simply begin to fail and the 'storage engine' errors appear.  The only common thread I seem to see is that it occurs after inserting data.  If the DB is static and no data is inserted I can't ever recall seeing the data corruption issue.

Suggested fix:
Currently my work around is to swear at the computer and then manually run REPAIR TABLE ... from the mysql CLI an run myisamchk afterwards.

It's not really a work around... rather a band aid.

Apple has posted this:

http://docs.info.apple.com/article.html?artnum=107852

which references a 'byte-ordering issue' which I have seen batted around in some OS X mailing lists.  I went as so far as to export and import all my db's on all systems.  Still no luck.

The most recent incident was on a OS X 10.4.1 Server system running 4.1.12.  The db / table in question was brand new and did not go though any Apple OS or MySQL upgrade.
[20 Jul 2005 18:17] MySQL Verification Team
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.mysql.com/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to 'Open'.

Thank you for your interest in MySQL.
[20 Jul 2005 18:43] Dan Tappin
OK... I read:

http://bugs.mysql.com/how-to-report.php

The basics: what you did:

inserted data (non specific - multiple tables) normal INSERT INTO table SET a = 1 , b = 'foo'

what you expected to happen

expected non-corrupted data to be inserted

and what happened:

Error 127 randomly results on subsequent queries to the recently inserted table.

Always search the bug database first.

I did.  Could not find a simular bug.  If I have a duplicate please advise.

If you don't understand an error message, ask for help.

I understand the error message.  I have a corrupted table.  I fix the table, insert more data and the error returns.

Use English.

I used English.

Don't report bugs about old versions.

4.1.13 is new I am running 4.1.12. The issue has been in several recent revs.

Only report one problem in each bug report.

I have only reported one bug.

Could you perhaps be more specific as to what info I am missing?  My post describes the issue and the versions of the software I am using and I think I meet the guidelines for posting.

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.050 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.