Failing assertion: page_is_comp(get_block->frame) == page_is_comp(page)

Bug #939248 reported by yinfeng on 2012-02-23
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
MySQL Server
Unknown
Unknown
Percona Server
High
Unassigned
5.1
High
Unassigned
5.5
High
Unassigned
5.6
High
Unassigned

Bug Description

version: mysql5.1.48

Recently we got a assertion failure as follows:

120221 3:53:51 InnoDB: Assertion failure in thread 1299265856 in file btr/btr0cur.c
line 245
InnoDB: Failing assertion: page_is_comp(get_block->frame) == page_is_comp(page)

After this the server crash we tried to restart mysqld and always got another failure
even with innodb_force_recovery(1-5):

120221 3:54:15 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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 34 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 75 76 77 78 79 80 81 82 83 84 85
86 87 88 89 120221 3:54:52 InnoDB: Assertion failure in thread 1138456896 in file
log/log0recv.c line 1216
InnoDB: Failing assertion: !page || (ibool)!!page_is_comp(page) ==
dict_table_is_comp(index->table)

while innodb_force_recovery was set to 6 ,there's a different assert failure happened

120221 22:39:40 InnoDB: error: space object of table'lg_core_0007/lg_order_0472',
InnoDB: space id 2017 did not exist in memory. Retrying an open.
120221 22:39:40 InnoDB: Assertion failure in thread 1331177792 in file fil/fil0fil.c
line 2982
InnoDB: Failing assertion: flags != DICT_TF_COMPACT

Stewart Smith (stewart) on 2012-06-15
Changed in percona-server:
importance: Undecided → High
yinfeng (yinfeng-zwx) wrote :
Download full text (3.7 KiB)

we got a similar crash, the printed information is a little different. we are using Percona Server 5.5.18

130401 23:27:45 InnoDB: Assertion failure in thread 1348516160 in file btr0pcur.c line 414
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.
130401 23:27:45 - 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=104857600
read_buffer_size=1048576
max_used_connections=526
max_threads=2100
thread_count=233
connection_count=233
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 3118475 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x2ab3f0d877f0
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 = 0x5060b0f8 thread_stack 0x80000
/u01/mysql/bin/mysqld(my_print_stacktrace+0x39)[0x7ca5a9]
/u01/mysql/bin/mysqld(handle_segfault+0x36d)[0x4ebded]
/lib64/libpthread.so.0[0x3b7d20e7c0]
/lib64/libc.so.6(gsignal+0x35)[0x3b7ca30265]
/lib64/libc.so.6(abort+0x110)[0x3b7ca31d10]
/u01/mysql/bin/mysqld[0x856842]
/u01/mysql/bin/mysqld[0x80db78]
/u01/mysql/bin/mysqld[0x7e0ad1]
/u01/mysql/bin/mysqld[0x59bd3b]
/u01/mysql/bin/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x70)[0x5971f0]
/u01/mysql/bin/mysqld[0x597694]
/u01/mysql/bin/mysqld(_ZN4JOIN4execEv+0x1272)[0x5a86f2]
/u01/mysql/bin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x192)[0x5a9bc2]
/u01/mysql/bin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x1cb)[0x5aa5eb]
/u01/mysql/bin/mysqld[0x566200]
/u01/mysql/bin/mysqld(_Z21mysql_execute_commandP3THD+0x17b0)[0x568fc0]
/u01/mysql/bin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x3ad)[0x56e4cd]
/u01/mysql/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x13ca)[0x56f8aa]
/u01/mysql/bin/mysqld(_Z10do_commandP3THD+0x106)[0x56fc06]
/u01/mysql/bin/mysqld(_Z24do_handle_one_connectionP3THD+0x125)[0x60c715]
/u01/mysql/bin/mysqld(handle_one_connection+0x4c)[0x60c83c]
/lib64/libpthread.so.0[0x3b7d2064a7]
/lib64/libc.so.6(clone+0x6d)[0x3b7cad3c2d]

after this . this instance keeps on crash again and again:

InnoDB: a nonsensical page number 0 in a node ptr record at offset 101
130401 23:51:10 InnoDB: Page dump in ascii and...

Read more...

Przemek (pmalkowski) wrote :
Download full text (3.2 KiB)

Happened also on PS 5.5.23 in exactly the same line/function:

140303 15:56:35 InnoDB: Assertion failure in thread 1263663424 in file btr0pcur.c line 455
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.
15:56:35 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=8388608
read_buffer_size=131072
max_used_connections=6
max_threads=1350
thread_count=3
connection_count=3
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2962329 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x15dd4960
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 = 4b51f0f8 thread_stack 0x80000
/usr/sbin/mysqld(my_print_stacktrace+0x35)[0x7a3b95]
/usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0x67f474]
/lib64/libpthread.so.0[0x3b30a0eb10]
/lib64/libc.so.6(gsignal+0x35)[0x3b30630265]
/lib64/libc.so.6(abort+0x110)[0x3b30631d10]
/usr/sbin/mysqld[0x82c6c5]
/usr/sbin/mysqld[0x7db797]
/usr/sbin/mysqld[0x7dc22d]
/usr/sbin/mysqld[0x7b341d]
/usr/sbin/mysqld(_ZN7handler15read_range_nextEv+0x2d)[0x68061d]
/usr/sbin/mysqld(_ZN7handler21read_multi_range_nextEPP18st_key_multi_range+0x2d)[0x67fd9d]
/usr/sbin/mysqld(_ZN18QUICK_RANGE_SELECT8get_nextEv+0x41)[0x72f4d1]
/usr/sbin/mysqld[0x745e6b]
/usr/sbin/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x79)[0x5a9569]
/usr/sbin/mysqld[0x5ae150]
/usr/sbin/mysqld(_ZN4JOIN4execEv+0xc7e)[0x5c38be]
/usr/sbin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x12c)[0x5bf38c]
/usr/sbin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x1cd)[0x5c511d]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x3c6c)[0x588eac]
/usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x333)[0x589d53]
/usr/sbin/mysqld(_ZN15Query_log_event14do_apply_eventEPK14Relay_log_infoPKcj+0xcc8)[0x725468]
/usr/sbin/mysqld(_Z26apply_event_and_update_posP9Log_eventP3THDP14Relay_log_info+0x125)[0x528275]
/usr/sbin/mysqld[0x52cd39]
/usr/sbin/mysqld(handle_slave_sql+0x919)[0x52e109]
/lib64/libpthread.so.0[0x3b30a0673d]
/lib64/libc.so.6(clone+0x6d)[0x3b306d3d1d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query ...

Read more...

tags: added: i39912
tags: added: upstream

We still miss a repeatable test case for this bug. Related upstream bug is also "Open".

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.