MySQL Bugs: #58655: Assertion failed, server crashes with mysqld got signal 6

Bug #58655	Assertion failed, server crashes with mysqld got signal 6
Submitted:	2 Dec 2010 12:38	Modified:	13 Jun 2011 12:54
Reporter:	Nidhi Shrotriya	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	5.1.55-debug	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
Server crashes as mysqld got signal 6 below:

Version: '5.1.55-debug'  socket: '/export/home/pb2/test/sb_1-2609820-1291186096.68/mysql-5.1.55-linux-x86_64-test/vardirs/mysql.sock'  port: 50004  Source distribution
101201  8:30:05  InnoDB: ERROR: the age of the last checkpoint is 9445089,
InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.
101201  8:30:21  InnoDB: ERROR: the age of the last checkpoint is 11379815,
InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.
mysqld: field.cc:3511: virtual longlong Field_medium::val_int(): Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed.
101201  8:31:03 - 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=8384512
read_buffer_size=131072
max_used_connections=62
max_threads=151
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338340 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd: 0x2aaaac5008d0
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 = 0x453341a0 thread_stack 0x40000
/export/home/pb2/test/sb_1-2609820-1291186096.68/mysql-5.1.55-linux-x86_64-test/libexec/mysqld(my_print_stacktrace+0x32)[0x9ebd9c]
/export/home/pb2/test/sb_1-2609820-1291186096.68/mysql-5.1.55-linux-x86_64-test/libexec/mysqld(handle_segfault+0x28a)[0x644880]
/lib64/libpthread.so.0[0x2b170be2fc00]
/lib64/libc.so.6(gsignal+0x35)[0x2b170c413bb5]
/lib64/libc.so.6(abort+0x110)[0x2b170c414fb0]
/lib64/libc.so.6(__assert_fail+0xf6)[0x2b170c40d286]
/export/home/pb2/test/sb_1-2609820-1291186096.68/mysql-5.1.55-linux-x86_64-test/libexec/mysqld(_ZN12Field_medium7val_intEv+0x69)[0x60a1ad]
/export/home/pb2/test/sb_1-2609820-1291186096.68/mysql-5.1.55-linux-x86_64-test/libexec/mysqld(_ZN12ha_partition28set_auto_increment_if_higherEP5Field+0x43)[0x7ac94b]
/export/home/pb2/test/sb_1-2609820-1291186096.68/mysql-5.1.55-linux-x86_64-test/libexec/mysqld(_ZN12ha_partition10update_rowEPKhPh+0x3b6)[0x7a6062]
/export/home/pb2/test/sb_1-2609820-1291186096.68/mysql-5.1.55-linux-x86_64-test/libexec/mysqld(_ZN7handler13ha_update_rowEPKhPh+0x6e)[0x79620a]
/export/home/pb2/test/sb_1-2609820-1291186096.68/mysql-5.1.55-linux-x86_64-test/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesb+0x178d)[0x7117fd]
/export/home/pb2/test/sb_1-2609820-1291186096.68/mysql-5.1.55-linux-x86_64-test/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x2eb4)[0x65851e]
/export/home/pb2/test/sb_1-2609820-1291186096.68/mysql-5.1.55-linux-x86_64-test/libexec/mysqld(_Z11mysql_parseP3THDPcjPPKc+0x2cf)[0x65ec6d]
/export/home/pb2/test/sb_1-2609820-1291186096.68/mysql-5.1.55-linux-x86_64-test/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0xd25)[0x6605e9]
/export/home/pb2/test/sb_1-2609820-1291186096.68/mysql-5.1.55-linux-x86_64-test/libexec/mysqld(_Z10do_commandP3THD+0x253)[0x661a61]
/export/home/pb2/test/sb_1-2609820-1291186096.68/mysql-5.1.55-linux-x86_64-test/libexec/mysqld(handle_one_connection+0x13f)[0x64da77]
/lib64/libpthread.so.0[0x2b170be28143]
/lib64/libc.so.6(__clone+0x6d)[0x2b170c4a48cd]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x16ad030 = UPDATE part_tbl_i2 SET filler='Updating the row' WHERE uid=298
thd->thread_id=111
thd->killed=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:
Running partitions-upgrade-5-1-major.test in SystemQA upgrade/downgrade framework fails as below, due to the above issue.
At line 238: query 'UPDATE part_tbl_i2 SET filler='Updating the row' WHERE uid=298' failed: 2013: Lost connection to MySQL server during query

Investigating to provide the exact steps.

Exact Steps to reproduce:
=======================
Pick 5.1.55 build from http://trollheim.norway.sun.com/archive/2776783.mysql-5.1.55-linux-x86_64.tar.gz

Start server, execute below commands from mysql commandline. 

USE test;
CREATE TABLE part_tbl_i2 (
       id MEDIUMINT NOT NULL AUTO_INCREMENT,
       dt DATE, st VARCHAR(255), uid INT,
       id2nd LONGBLOB, filler VARCHAR(255), PRIMARY KEY(id, dt)
);
INSERT INTO part_tbl_i2 (dt, st, uid, id2nd, filler) VALUES 
   ('1991-03-14', 'Initial Insert', 200, 1234567, 'No Data'),
   ('1991-02-26', 'Initial Insert', 201, 1234567, 'No Data'),
   ('1992-03-16', 'Initial Insert', 234, 1234567, 'No Data'),
   ('1992-07-02', 'Initial Insert', 287, 1234567, 'No Data'),
   ('1991-05-26', 'Initial Insert', 256, 1234567, 'No Data'),
   ('1991-04-25', 'Initial Insert', 222, 1234567, 'No Data'),
   ('1993-03-12', 'Initial Insert', 267, 1234567, 'No Data'),
   ('1993-03-14', 'Initial Insert', 291, 1234567, 'No Data'),
   ('1991-12-20', 'Initial Insert', 298, 1234567, 'No Data'),
   ('1994-10-31', 'Initial Insert', 220, 1234567, 'No Data');
ALTER TABLE part_tbl_i2 PARTITION BY LIST (YEAR(dt)) (
    PARTITION d1 VALUES IN (1991, 1994),
    PARTITION d2 VALUES IN (1993),
    PARTITION d3 VALUES IN (1992, 1995, 1996)
);
INSERT INTO part_tbl_i2 (dt, st, uid, id2nd, filler) VALUES 
   ('1991-07-14', 'After Partitioning Insert', 299, 1234567, 'Insert row');
UPDATE part_tbl_i2 SET filler='Updating the row' WHERE uid=298;

Crashes on the above update statement.

Seen only with debug builds. 
http://trollheim.norway.sun.com/archive/2805176.mysql-5.1.56-linux-x86_64.tar.gz

Documented as follows in the 5.1.59, 5.1.15, and 5.6.3 changelogs:

      Auto-increment columns of partitioned tables were checked even when they
      were not being written to. In debug builds, this could lead to a crash of
      the server.

Closed.