[MDEV-634] LP:618401 - InnoDB recovery crash in MySQL 5.0.75 @log0recv.c Created: 2010-08-15  Updated: 2014-03-03  Resolved: 2014-03-03

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Thomas (Inactive) Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: Launchpad, upstream

Attachments: XML File LPexportBug618401.xml     Text File LPexportBug618401_mariadb-5.1.49-innodb-x86_64-binary.log    

 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.

 Comments   
Comment by Rasmus Johansson (Inactive) [ 2010-08-15 ]

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!

Comment by Rasmus Johansson (Inactive) [ 2010-08-15 ]

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.

Comment by Thomas (Inactive) [ 2010-08-15 ]

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

Comment by Thomas (Inactive) [ 2010-08-15 ]

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

Comment by Rasmus Johansson (Inactive) [ 2010-08-15 ]

Launchpad bug id: 618401

Generated at Thu Feb 08 06:30:12 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.