Bug #75915 Assertion failure in file btr0pcur.c line 428
Submitted: 16 Feb 2015 8:59 Modified: 20 Mar 2015 20:53
Reporter: Sven Rausch Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S1 (Critical)
Version:5.5.41 OS:Linux (Ubuntu 12.04 LTS)
Assigned to: CPU Architecture:Any
Tags: crash, innodb, querying data

[16 Feb 2015 8:59] Sven Rausch
Description:
Hello,

when I try to perform a SELECT,CHECK TABLE or use mysqldump on one specific table in my database the whole mysql server crashes and restarts. 

According to 'innochecksum' all pages are okay. 

I already tried to use force_innodb_recovery <= 6 but the server passes away and I get a lost connection error when dumping table at row '6199219'. Even on some normal queries a crash occur. Row number is always the same.

Here is what my errorlog says about the crash:

sr@kirk:~$ sudo mysqld --console --verbose
150215 19:20:15 [Note] Plugin 'FEDERATED' is disabled.
150215 19:20:15 InnoDB: The InnoDB memory heap is disabled
150215 19:20:15 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150215 19:20:15 InnoDB: Compressed tables use zlib 1.2.3.4
150215 19:20:15 InnoDB: Initializing buffer pool, size = 20.0G
150215 19:20:18 InnoDB: Completed initialization of buffer pool
150215 19:20:18 InnoDB: highest supported file format is Barracuda.
150215 19:20:22  InnoDB: Waiting for the background threads to start
150215 19:20:23 InnoDB: 5.5.41 started; log sequence number 80382959696
150215 19:20:23 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
150215 19:20:23 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
150215 19:20:23 [Note] Server socket created on IP: '0.0.0.0'.
150215 19:20:23 [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.
150215 19:20:23 [ERROR] Server id not set, will not start slave
150215 19:20:23 [ERROR] Failed to create slave threads
150215 19:20:23 [Note] Event Scheduler: Loaded 0 events
150215 19:20:23 [Note] mysqld: ready for connections.
Version: '5.5.41-0ubuntu0.12.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
150215 19:22:28  InnoDB: Assertion failure in thread 140612062639872 in file btr0pcur.c line 428
InnoDB: Failing assertion: page_is_comp(next_page) == page_is_comp(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.
18:22:28 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.

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

Thread pointer: 0x7fe83528e930
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 = 7fe2cc0b6e60 thread_stack 0x30000
mysqld(my_print_stacktrace+0x29)[0x7fe814a2bd79]
mysqld(handle_fatal_signal+0x483)[0x7fe8148f0923]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7fe81361fcb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7fe812c860d5]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7fe812c8983b]
mysqld(+0x63ddbd)[0x7fe814b0ddbd]
mysqld(+0x5f7eee)[0x7fe814ac7eee]
mysqld(+0x5dae0c)[0x7fe814aaae0c]
mysqld(_Z13rr_sequentialP11READ_RECORD+0x19)[0x7fe8149c4e59]
mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x71)[0x7fe8147f5bf1]
mysqld(+0x336914)[0x7fe814806914]
mysqld(_ZN4JOIN4execEv+0xc03)[0x7fe814816563]
mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x130)[0x7fe814811cb0]
mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x17c)[0x7fe814817cdc]
mysqld(+0x2fb9b4)[0x7fe8147cb9b4]
mysqld(_Z21mysql_execute_commandP3THD+0x16a6)[0x7fe8147d3a06]
mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x10f)[0x7fe8147d8c1f]
mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1f26)[0x7fe8147dac16]
mysqld(_Z24do_handle_one_connectionP3THD+0x1bd)[0x7fe81488198d]
mysqld(handle_one_connection+0x50)[0x7fe8148819f0]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7fe813617e9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fe812d442ed]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7fe268004b60): is an invalid pointer
Connection ID (thread ID): 14
Status: NOT_KILLED

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:

Restarting the server and perform a Query like 'SELECT * FROM table' on the table.
[20 Feb 2015 20:53] Sveta Smirnova
Thank you for the report.

Unfortunately we need your data to identify if this is really corruption or not(most likely this is really corrupted data).

But you can restore rows less than 6199219, just use WHERE clause in the SELECT * FROM table statement. You can also try to restore rows after 6199219, but you need to try each one: 6199220, 6199221 and so on until error stopped occurring. Few rows will be missed unfortunately.
[21 Mar 2015 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".