Details
Major
Description
This is a duplicate of <http://bugs.mysql.com/bug.php?id=29221> - but I don't want to feed the Oracle trolls over there anymore so I report it here (sorry if this is not wanted). The invariant in question which lets it crash after about 75% of recovery is
!page || (ibool)!!page_is_comp(page)==index->table->comp
This is the full log:
Aug 15 22:29:44 herculaneum mysqld_safe[9069]: started Aug 15 22:29:44 herculaneum mysqld[9072]: InnoDB: Log scan progressed past the checkpoint lsn 286 2463577034 Aug 15 22:29:44 herculaneum mysqld[9072]: 100815 22:29:44 InnoDB: Database was not shut down normally! Aug 15 22:29:44 herculaneum mysqld[9072]: InnoDB: Starting crash recovery. Aug 15 22:29:44 herculaneum mysqld[9072]: InnoDB: Reading tablespace information from the .ibd files... Aug 15 22:29:44 herculaneum mysqld[9072]: InnoDB: Restoring possible half-written data pages from the doublewrite Aug 15 22:29:44 herculaneum mysqld[9072]: InnoDB: buffer... Aug 15 22:29:44 herculaneum mysqld[9072]: 100815 22:29:44 InnoDB: Starting an apply batch of log records to the database... Aug 15 22:29:44 herculaneum mysqld[9072]: InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 3 4 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 100815 22:29:44InnoDB: Assertion failure in thread 140592965253456 in file log0recv.c line 793 Aug 15 22:29:44 herculaneum mysqld[9072]: InnoDB: Failing assertion: !page || (ibool)!!page_is_comp(page)==index->table->comp Aug 15 22:29:44 herculaneum mysqld[9072]: InnoDB: We intentionally generate a memory trap. Aug 15 22:29:44 herculaneum mysqld[9072]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com. Aug 15 22:29:44 herculaneum mysqld[9072]: InnoDB: If you get repeated assertion failures or crashes, even Aug 15 22:29:44 herculaneum mysqld[9072]: InnoDB: immediately after the mysqld startup, there may be Aug 15 22:29:44 herculaneum mysqld[9072]: InnoDB: corruption in the InnoDB tablespace. Please refer to Aug 15 22:29:44 herculaneum mysqld[9072]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html Aug 15 22:29:44 herculaneum mysqld[9072]: InnoDB: about forcing recovery. Aug 15 22:29:44 herculaneum mysqld[9072]: 100815 22:29:44 - mysqld got signal 11 ; Aug 15 22:29:44 herculaneum mysqld[9072]: This could be because you hit a bug. It is also possible that this binary Aug 15 22:29:44 herculaneum mysqld[9072]: or one of the libraries it was linked against is corrupt, improperly built, Aug 15 22:29:44 herculaneum mysqld[9072]: or misconfigured. This error can also be caused by malfunctioning hardware. Aug 15 22:29:44 herculaneum mysqld[9072]: We will try our best to scrape up some info that will hopefully help diagnose Aug 15 22:29:44 herculaneum mysqld[9072]: the problem, but since we have already crashed, something is definitely wrong Aug 15 22:29:44 herculaneum mysqld[9072]: and this may fail. Aug 15 22:29:44 herculaneum mysqld[9072]: Aug 15 22:29:44 herculaneum mysqld[9072]: key_buffer_size=0 Aug 15 22:29:44 herculaneum mysqld[9072]: read_buffer_size=131072 Aug 15 22:29:44 herculaneum mysqld[9072]: max_used_connections=0 Aug 15 22:29:44 herculaneum mysqld[9072]: max_connections=100 Aug 15 22:29:44 herculaneum mysqld[9072]: threads_connected=0 Aug 15 22:29:44 herculaneum mysqld[9072]: It is possible that mysqld could use up to Aug 15 22:29:44 herculaneum mysqld[9072]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 217599 K Aug 15 22:29:44 herculaneum mysqld[9072]: bytes of memory Aug 15 22:29:44 herculaneum mysqld[9072]: Hope that's ok; if not, decrease some variables in the equation. Aug 15 22:29:44 herculaneum mysqld[9072]: Aug 15 22:29:44 herculaneum mysqld[9072]: thd=(nil) Aug 15 22:29:44 herculaneum mysqld[9072]: Attempting backtrace. You can use the following information to find outAug 15 22:29:44 herculaneum mysqld[9072]: where mysqld died. If you see no messages after this, something went Aug 15 22:29:44 herculaneum mysqld[9072]: terribly wrong... Aug 15 22:29:44 herculaneum mysqld[9072]: frame pointer is NULL, did you compile with Aug 15 22:29:44 herculaneum mysqld[9072]: -fomit-frame-pointer? Aborting backtrace! Aug 15 22:29:44 herculaneum mysqld[9072]: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains Aug 15 22:29:44 herculaneum mysqld[9072]: information that should help you find out what is causing the crash. Aug 15 22:29:44 herculaneum mysqld_safe[9079]: ended
If needed, please give me further pointers how to create a proper backtrace so you can nail the issue down. Thanks for reading.
Gliffy Diagrams
Attachments
Issue Links
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Re: InnoDB recovery crash in MySQL 5.0.75 @log0recv.c
I should point out that in MariaDB we have replaced InnoDB with XtraDB. It may be useful to test this same issue against XtraDB, and if the problem does not exist with this engine, migrate your installation to MariaDB+XtraDB.
Attached is the log for MariaDB 5.1.49 - the recovery does not go through here either, but this time different invariants and other weird failures seem to popup.
What I did to generate this log:
1) cp /var/lib/mysql to /var/lib/mysql-bkp
2) run `bin/mysqld_safe --debug --verbose --datadir=/var/lib/mysql-bkp --user=mysql` from inside the 5.1.49 tarball while keeping the original 5.0.x installation unchanged
mariadb-5.1.49-innodb-x86_64-binary.log
LPexportBug618401_mariadb-5.1.49-innodb-x86_64-binary.log
Re: InnoDB recovery crash in MySQL 5.0.75 @log0recv.c
Attached is the log for MariaDB 5.1.49 - the recovery does not go through here either, but this time different invariants and other weird failures seem to popup.
What I did to generate this log:
1) cp /var/lib/mysql to /var/lib/mysql-bkp
2) run `bin/mysqld_safe --debug --verbose --datadir=/var/lib/mysql-bkp --user=mysql` from inside the 5.1.49 tarball while keeping the original 5.0.x installation unchanged
Launchpad bug id: 618401
Re: InnoDB recovery crash in MySQL 5.0.75 @log0recv.c
Could you please try to replicate this issue in the current stable version of MariaDB (5.1.49) to confirm that this bug has not already been addressed by our developers?
http://askmonty.org/wiki/MariaDB:Download
Thanks!