Bug #29221 InnoDB asserts in log0recv.c when
Submitted: 19 Jun 2007 19:32 Modified: 13 Sep 2007 12:40
Reporter: Ron Parker Email Updates:
Status: No Feedback Impact on me:
Category:MySQL Server: InnoDB storage engine Severity:S1 (Critical)
Version:5.0.22 OS:Linux (RHEL 5)
Assigned to: Assigned Account CPU Architecture:Any

[19 Jun 2007 19:32] Ron Parker
After shutting down and restarting our server, InnoDB reports that the database was not shut down normally, starts crash recovery and while applying a batch of log records to the database it asserts in log0recv.c with:

InnoDB: Failing assertion: !page || (ibool)!!page_is_comp(page)==index->table->comp

How to repeat:
Just attempt to restart our database.
[19 Jun 2007 19:34] Ron Parker
mysqld.log when trying to start the database

Attachment: mysql-error.txt (text/plain), 3.06 KiB.

[20 Jun 2007 4:28] Valeriy Kravchuk
Thank you for a problem report. Can you, please, send a resolved stack trace and explain what happened before this assertion failure.
[20 Jun 2007 12:08] Marko Mäkelä
If the page in question is filled with zeroes, this could be a duplicate of Bug #23710.
[20 Jun 2007 12:08] Heikki Tuuri
This may be duplicate of http://bugs.mysql.com/bug.php?id=23710

Did mysqld originally crash VERY QUICKLY (in less than 10 seconds) after a mysqld startup?

[20 Jun 2007 12:16] Heikki Tuuri

can you post the entire .err log, also from before this latest crash?

[20 Jun 2007 17:26] Ron Parker
Entire mysqld.log from server setup until after the crash

Attachment: mysqld.log (application/octet-stream, text), 436.12 KiB.

[20 Jun 2007 17:41] Ron Parker
Unfortunately I didn't have any symbols available when I tried to run nm on mysqld_safe or mysqld_multi.

I am working several hours away from this server, but learned that a number of other machines where the server is housed just completely fell over about the time this error occurred.

Upon trying to force recovery of the database one table was irretrievably corrupted, one other had a recoverable error and others just had warnings.  Dumping the databases, erasing the old tablespace, restarting MySQL, reloading the databases and recreating the destroyed table seems to have gotten us back on-line.

I am currently packaging up the database and my.cnf.  A tar.gz was a little under 700MB.  I just finished repackaging it as a tar.bz2 (532MiB) and will make that available to the developers from our website.
[21 Jun 2007 13:08] Marko Mäkelä
I grabbed the database files but did not get around to analyzing them yet. This is not likely to be a duplicate of Bug #23710, because all InnoDB tables are in a single tablespace.

According to a private comment, the server may have been affected by power outage. I would tend to blame the hardware or the operating system. fsync is often broken:


It would be very interesting if you could check the hardware and operating system with the diskchecker.pl tool from Brad Fitzpatrick's log above.  I will have a look at this in August, after my vacation.
[13 Aug 2007 12:40] Marko Mäkelä
did you rule out hardware failure?
[13 Sep 2007 23:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".