Bug #72237 MySQL Crash
Submitted: 4 Apr 2014 13:08 Modified: 7 May 2014 19:22
Reporter: Luis Joui Email Updates:
Status: No Feedback Impact on me:
Category:MySQL Server Severity:S1 (Critical)
Version:5.5.35-0ubuntu0.12.04.2 OS:Linux (ubuntu0.12.04.2)
Assigned to: CPU Architecture:Any
Tags: btr0cur.c, crash

[4 Apr 2014 13:08] Luis Joui

We have Mysql Installed on a Virtual Server (VMWare) running over ubuntu Server 12.04.2. It works fine around 2 or 3 weeks and then crush always in btr0cur.c but in different lines. 

When we try to restart the sevice, then it go to stop and the error Log shows:

140404  9:37:13 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
140404  9:37:13 [Note] Plugin 'FEDERATED' is disabled.
140404  9:37:13 InnoDB: The InnoDB memory heap is disabled
140404  9:37:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140404  9:37:13 InnoDB: Compressed tables use zlib
140404  9:37:13 InnoDB: Initializing buffer pool, size = 256.0M
140404  9:37:13 InnoDB: Completed initialization of buffer pool
140404  9:37:13 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
140404  9:37:13  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Last MySQL binlog file position 0 107, file name /var/log/mysql/mysql-bin.001686
140404  9:37:14  InnoDB: Waiting for the background threads to start
140404  9:37:15 InnoDB: 5.5.35 started; log sequence number 15782429751
140404  9:37:15 [Note] Recovering after a crash using /var/log/mysql/mysql-bin
140404  9:37:15 [Note] Starting crash recovery...
140404  9:37:15 [Note] Crash recovery finished.
140404  9:37:15 [Note] Server hostname (bind-address): ''; port: 3306
140404  9:37:15 [Note]   - '' resolves to '';
140404  9:37:15 [Note] Server socket created on IP: ''.
140404  9:37:16 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use '--relay-log=mysqld-relay-bin' to avoid this problem.
140404  9:37:16 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000077' at position 80032659, relay log './mysqld-relay-bin.000062' position: 79106336
140404  9:37:16 [Note] Slave I/O thread: connected to master 'wisereplicador@',replication started in log 'mysql-bin.000077' at position 80037761
140404  9:37:16 [Note] Event Scheduler: Loaded 0 events
140404  9:37:16 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.35-0ubuntu0.12.04.2-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
140404  9:37:18  InnoDB: Assertion failure in thread 139757630732032 in file btr0cur.c line 277
InnoDB: Failing assertion: btr_page_get_next(get_block->frame, mtr) == page_get_page_no(page)
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
12:37:18 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.

It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 516800 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f1b98000990
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f1bdbef2820 thread_stack 0x31000

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): is an invalid pointer
Connection ID (thread ID): 1

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

How to repeat:
We don't know
[4 Apr 2014 19:46] Sveta Smirnova
Thank you for the report.

Please check your disk on errors: assertion complains about pages, which are read from the disk.
[7 Apr 2014 15:06] Luis Joui
The server is a VPS and our service provider said "the disk has no physical problems (physical disk of their virtual machines is a RAID storage, which they have monitored)"
Is there any way to define/detect the disk problem to tell it to our service provider?
Is there a MySQL configuration to avoid this problem? or at least avoid the database corruption?
[7 Apr 2014 19:22] Sveta Smirnova
Thank you the feedback.

Not, you need to use OS tools to check if disk is corrupted or not.

Regarding to the question about how to avoid corruption: yes, there are InnoDB options, which can help, particularly innodb_doublewrite and innodb_flush_log_at_trx_commit (http://dev.mysql.com/doc/refman/5.5/en/mysqld-option-tables.html)

Since you cannot check if disk was corrupted or not please send us full error log file and try to identify if repeating scenario leads to crash, so we can be sure this is not MySQL bug.
[8 May 2014 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".