Bug #67528 Failing assertion: page_no != FIL_NULL after upgrade from 5.1 to 5.5
Submitted: 8 Nov 2012 22:03 Modified: 15 Mar 2013 17:48
Reporter: Martin von Gagern Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S3 (Non-critical)
Version:5.5 OS:Any
Assigned to: CPU Architecture:Any

[8 Nov 2012 22:03] Martin von Gagern
Description:
After upgrading from 5.1 to 5.5, my server failed to start, reporing the following message:

121108  7:00:31 InnoDB: highest supported file format is Barracuda.
121108  7:00:31  InnoDB: Warning: allocated tablespace 5, old maximum was 0
121108  7:00:31  InnoDB: Assertion failure in thread 140230384047936 in file trx0rseg.c line 337
InnoDB: Failing assertion: page_no != FIL_NULL
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.

I first reported this at https://bugs.gentoo.org/show_bug.cgi?id=442346 including more detailed stack traces, and got valuable help there from Brian Evans. It seems that this is due to my ibdata1 tablespace file reaching the configured size limit.

Changing that limit does solve the issue. So my core concern is the fact that this issue was handled so gracelessly: a failed assertion, followed by a SIGABRT, a backtrace and a termination of the server hardly seem like an appropriate handling for a case where a user-configured resource limit was reached.

When the same table data was recreated from a dump, the ibdata1 file was mere 19M in size, so it seems to me that InnoDB doesn't scale particularly well. Having to dump and reload my tables on a regular basis to keep file sizes down doesn't feel like a particularly good solution. I'm a bit surprised that I couldn't find a bug report about this more general issue.

How to repeat:
Create large InnoDB data base in MySQL 5.1, up to the limit of the tablespace file. Then upgrade to 5.5 and restart mysqld. I haven't tried whether this works in general, or whether additional conditions are required to make 5.5 require more space than 5.1 did.

Suggested fix:
Increase the max value of the innodb_data_file_path setting.
See http://dev.mysql.com/doc/refman/5.5/en/innodb-configuration.html
[8 Nov 2012 22:33] Martin von Gagern
OK, I found bug 1341 about shrinking the ibdata file, so that request is out there. So let's concentrate here on a more graceful reporting of a reached size limit.
[10 Nov 2012 0:54] Sveta Smirnova
Thank you for the report.

I can not repeat crash: MySQL server starts fine. Looks like this depends from your ibdata files. If you meet same error again, please upload these files to our server.
[10 Nov 2012 19:02] Martin von Gagern
As the database contains confidential information, I cannot upload that whole ibdata1 file here. If there is any particular aspect of it which you want me to investigate, I'll try to help.
[5 Jan 2013 13:06] MySQL Verification Team
Apparently (haven't tested), this should have been fixed in 5.6 with the separate undo tables patch.. 

http://dev.mysql.com/doc/refman/5.6/en/innodb-performance.html#innodb-undo-tablespace

Also should fix http://bugs.mysql.com/bug.php?id=57387
[15 Feb 2013 17:48] Sveta Smirnova
Please try with just released version 5.6.10 as Shane suggested and inform us if issue still exists.
[16 Mar 2013 1: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".