MySQL Bugs: #60757: MySQL server crush on InnoDB

Bug #60757	MySQL server crush on InnoDB
Submitted:	5 Apr 2011 7:20	Modified:	22 Jul 2011 13:48
Reporter:	Phil Kulin	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S1 (Critical)
Version:	5.5.2	OS:	FreeBSD (8.2 amd64)
Assigned to:		CPU Architecture:	Any
Tags:	crash, innodb

Description:
Some times MySQL crush with message:
 len 224; hex 703bc263000000009b00ae560000000080a77f4b00000000203b645e0000000000000000000000000300000000000000010000000000000000000000000000000300000000000000010000000000000002000000000000000000000000000000100000000000000000000000000000000000d7295e0000000100000000000000834451070000000075aa985e000000000200000000000000010000000000000080a77f4b00000000000000000000000060e111770000000002000000000000000000000000000000460000000000000070aa985e000000001000000000000000; asc p; c       V       K     ;d^                                                                                       )^            DQ     u  ^                       K            `  w                    F       p  ^            ;
110405  8:08:37  InnoDB: Assertion failure in thread 1607339008 in file btr/btr0pcur.c line 231
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.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
110405  8:08:37 - 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=134217728
read_buffer_size=1048576
max_used_connections=91
max_threads=500
threads_connected=7
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1160146 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

On 5.5.1 this repeat. I can´t find fix on newer releases. 

How to repeat:
Don´t know.

What exactly happened before you get this crash, at MySQL and OS level? Any hardware failures?

Please, send the entire error log (compressed if it is too big). Also you should not use 5.5.2, it is too old. Current version is 5.5.10.

Any ideas. All is normal. Crushes repeat periodically. Both at the loaded time and per the quiet. Any failures of the hardware. There was a thought that failure because of congestion of a disk, but bases are on the dedicated disk which doesn't show notable loading. I wrote down a binary log - any correlation with failures. I can send - small just with the end on failure. I compiled mysql with and without optimization, static and shared - no success effect.

Version 5.5.3 has incompatible changes because of which not probably to use many existing appendices. For example "CREATE .... TABLE TYPE...". I know that is time for a long time already, but here the hostage of a situation

Without the error log (and stack trace there, if any) I can say nothing useful. Moreover, if this problem was a result of a bug, we need to know if the bug is repeatable in recent version, 5.5.10+, and the bug can be fixed only in 5.5.12+.

And how to make stack trace? And what error_log? All I will make if it technically probably. Rebuld all to a smog. About 5.5.12 it is clear - I will make a patch for myself.

P.S. If there was at least an external patch on CREATE TABLE - in general the problem with the version wouldn't be.

Error log is usually a file named <hostname>.err in your datadir. You can execute the following in the mysql command line client (when server works) to get full pathname:

show variables like 'log_error';

Some failures in a error_log is our monitoring became crazy. When the server fell during loading, monitoring didn't distinguish timeout and try to restart it. In error_log also it is visible that included bin-log and changed the version.

This is a duplicate of bug #61101 (that bug is private).