MySQL Bugs: #24641: mysql crashes with the following error message

Bug #24641	mysql crashes with the following error message
Submitted:	28 Nov 2006 2:22	Modified:	1 Feb 2007 14:18
Reporter:	Yogish Baliga	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S3 (Non-critical)
Version:	4.1.21	OS:	Linux (RHEL4)
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
Version: '4.1.21-delicious-log'  socket: '/tmp/mysql.sock'  port: 3306  MySQL Community Edition - Standard (GPL)InnoDB: ERROR: Submit the output to http://bugs.mysql.comInnoDB: ibuf cursor restoration fails!InnoDB: ibuf record inserted to page 167897PHYSICAL RECORD: n_fields 8; 1-byte offs TRUE; info bits 0 0: len 4; hex 0000000d; asc     ;; 1: len 1; hex 00; asc  ;; 2: len 4; hex 00028fd4; asc     ;; 3: len 24; hex 86030004000001fd00800008860c00080000080000000000; asc                         ;; 4: len 4; hex 801325f9; asc   % ;; 5: len 5; hex 7061727473; asc parts;; 6: len 8; hex 8000123ed7d04ebf; asc    >  N ;; 7: len 6; hex 0000155af986; asc    Z  ;;PHYSICAL RECORD: n_fields 8; 1-byte offs TRUE; info bits 0 0: len 4; hex 0000000d; asc     ;; 1: len 1; hex 00; asc  ;; 2: len 4; hex 00028fd4; asc     ;; 3: len 24; hex 86030004000001fd00800008860c00080000080000000000; asc                         ;; 4: len 4; hex 801325f9; asc   % ;; 5: len 5; hex 7061727473; asc parts;; 6: len 8; hex 8000123ed7d04ebf; asc    >  N ;; 7: len 6; hex 0000155af986; asc    Z  ;;DATA TUPLE: 3 fields; 0: len 4; hex 0000000d; asc     ;; 1: len 1; hex 00; asc  ;; 2: len 4; hex 00028fd9; asc     ;;PHYSICAL RECORD: n_fields 1; 1-byte offs TRUE; info bits 0 0: len 9; hex 73757072656d756d00; asc supremum ;;InnoDB: Validating insert buffer tree:InnoDB: Dump of the child page:061127 21:08:07  InnoDB: Page dump in ascii and hex (16384 bytes):

061127 21:08:07  InnoDB: Page checksum 3888261714, prior-to-4.0.14-form checksum 2044893859
InnoDB: stored checksum 3888261714, prior-to-4.0.14-form stored checksum 2044893859
InnoDB: Page lsn 48 3537086419, low 4 bytes of lsn at page end 3537086419
InnoDB: Page number (if stored to page already) 13424,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an index page where index id is 4294967295 0
InnoDB: (index CLUST_IND of table SYS_IBUF_TABLE_0)
InnoDB: Dump of the parent page:
061127 21:08:07  InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex 

061127 21:08:07  InnoDB: Page checksum 210301552, prior-to-4.0.14-form checksum 2646883502
InnoDB: stored checksum 210301552, prior-to-4.0.14-form stored checksum 2646883502
InnoDB: Page lsn 48 3568489271, low 4 bytes of lsn at page end 3568489271
InnoDB: Page number (if stored to page already) 10651,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an index page where index id is 4294967295 0
InnoDB: (index CLUST_IND of table SYS_IBUF_TABLE_0)
InnoDB: Corruption of an index tree: table SYS_IBUF_TABLE_0, index CLUST_IND,
InnoDB: father ptr page no 9293, child page no 13424
PHYSICAL RECORD: n_fields 7; 1-byte offs TRUE; info bits 0
 0: len 4; hex 00000001; asc     ;; 1: len 1; hex 00; asc  ;; 2: len 4; hex 0001bdb8; asc     ;; 3: len 18; hex 860300040000860c00080000860300040000; asc                   ;; 4: len 4; hex 800266f6; asc   f ;; 5: len 8; hex 8000123ed7c350fa; asc    >  P ;; 6: len 4; hex 8755e3a9; asc  U  ;;
            n_owned: 0; heap_no: 2; next rec: 194
PHYSICAL RECORD: n_fields 8; 1-byte offs TRUE; info bits 0
 0: len 4; hex 00000001; asc     ;; 1: len 1; hex 00; asc  ;; 2: len 4; hex 0001c0e2; asc     ;; 3: len 18; hex 860300040000860c00080000860300040000; asc                   ;; 4: len 4; hex 8000b538; asc    8;; 5: len 8; hex 8000123ed7c12be5; asc    >  + ;; 6: len 4; hex 87503cf0; asc  P< ;; 7: len 4; hex 0000244d; asc   $M;;
            n_owned: 0; heap_no: 289; next rec: 7231
InnoDB: You should dump + drop + reimport the table to fix the
InnoDB: corruption. If the crash happens at the database startup, see
InnoDB: http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html about
InnoDB: forcing recovery. Then dump + drop + reimport.
061127 21:08:07InnoDB: Assertion failure in thread 1105209696 in file btr0btr.c line 618
InnoDB: Failing assertion: btr_node_ptr_get_child_page_no(node_ptr) == buf_frame_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/mysql/en/Forcing_recovery.html
InnoDB: about forcing recovery.
mysqld got signal 11;
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=8388600
read_buffer_size=2093056
max_used_connections=0
max_connections=500
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 5126188 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Number of processes running now: 0
061127 21:08:07  mysqld restarted

How to repeat:
I copied the mysql data files from the existing production server to the new server. Production server is running on 32 bit linux and new server is running on 64 bit Linux (RHEL4 on both)

In this bug report I have removed the hex dump. Please let me know if the hex dump is needed.

Thank you for a problem report. Please, take a look at a similar bug #10691. What exact MySQL version did you use on production server?

I copied the database from 4.1.18_3 to 4.1.21_0. Dumping the database and re-loading is going to take a long time. Is there any solution that would take less time?

If the corruption only occurs in the IBUF tree and it is due to some collation change between 4.1.18 and 4.1.21, then you could let the database run at zero workload under 4.1.8, so that InnoDB will merge the insert buffer. SHOW INNODB STATUS\G will say that 'Main thread state: waiting for server activity' when the insert buffer has been merged. Then you can retry the upgrade to 4.1.21.

Though I am not aware of any incompatible change between 4.1.18 and 4.1.21.

Please post your COMPLETE .err log from the history of that database. It can contain clues what caused the corruption.

Regards,

Heikki

I started the mysql server 4.1.18. Yet I am getting the following error message. What is the possible solution for this?

nnoDB: Assertion failure in thread 2888035248 in file ./../include/data0type.ic line 230
InnoDB: Failing assertion: charset_coll < 256
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/mysql/en/Forcing_recovery.html
InnoDB: about forcing recovery.
mysqld got signal 11;

Hi!

Please post all the contents from all .err logs associated with that MySQL database. I want to know what was the first error. Subsequent errors may be a result of the first error.

Regards,

Heikki

data0type.ic in 4.1.16:

/**************************************************************************
Reads to a type the stored information which determines its alphabetical
ordering and the storage size of an SQL NULL value. This is the >= 4.1.x
storage format. */
UNIV_INLINE
void
dtype_new_read_for_order_and_null_size(
/*===================================*/
        dtype_t*        type,   /* in: type struct */
        byte*           buf)    /* in: buffer for stored type order info */
{
        ulint   charset_coll;

        ut_ad(6 == DATA_NEW_ORDER_NULL_TYPE_BUF_SIZE);

        type->mtype = buf[0] & 63;
        type->prtype = buf[1];

        if (buf[0] & 128) {
                type->prtype = type->prtype | DATA_BINARY_TYPE;
        }

        type->len = mach_read_from_2(buf + 2);

        mach_read_from_2(buf + 4);

        charset_coll = mach_read_from_2(buf + 4);

        if (dtype_is_string_type(type->mtype)) {
                ut_a(charset_coll < 256);

                if (charset_coll == 0) {
                        /* This insert buffer record was inserted with MySQL
                        version < 4.1.2, and the charset-collation code was not
                        explicitly stored to dtype->prtype at that time. It
                        must be the default charset-collation of this MySQL
                        installation. */

                        charset_coll = data_mysql_default_charset_coll;
                }

                type->prtype = dtype_form_prtype(type->prtype, charset_coll);
        }
}

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".

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".