Bug #20521 InnoDB Assertion failure ALWAYS row0sel.c line 2378
Submitted: 17 Jun 2006 20:32 Modified: 20 Jun 2006 9:54
Reporter: Jeff C Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server Severity:S1 (Critical)
Version:5.1.11-Beta OS:Linux (RHEL4)
Assigned to: CPU Architecture:Any

[17 Jun 2006 20:32] Jeff C
Description:
Under load, mysql keeps restarting with assertion failures.

Similar bugs: 
id=20213 
id=10625
id=20486

Different tables, different times, yet always the same assertion: 
"InnoDB: Assertion failure in thread \d+ in file row0sel.c line 2378"

0x81b1877 handle_segfault + 423
0xbed888 (?)
(nil)
0x8263e62 index_read__11ha_innobasePcPCcUi16ha_rkey_function + 450
0x826423b index_first__11ha_innobasePc + 59
0x8264371 rnd_next__11ha_innobasePc + 65
0x824e92f rr_sequential__FP14st_read_record + 127
0x8209967 join_init_read_record__FP13st_join_table + 103
0x82088a0 sub_select__FP4JOINP13st_join_tableb + 208
0x8208590 do_select__FP4JOINPt4List1Z4ItemP8st_tableP9Procedure + 528
0x81fa793 exec__4JOIN + 5203
0x81fac87 mysql_select__FP3THDPPP4ItemP13st_table_listUiRt4List1Z4ItemP4ItemUiP8st_orderT7T5T7UlP13select_resultP18st_select_lex_unitP13s + 887
0x81f7111 Letext + 225
0x81c80cc mysql_execute_command__FP3THD + 8364
0x81cd288 mysql_parse__FP3THDPcUi + 328
0x81c4adf dispatch_command__F19enum_server_commandP3THDPcUi + 1903
0x81c435e do_command__FP3THD + 190
0x81c3864 handle_one_connection + 772
0xbe7371 (?)
0xb409be (?)

row=compact

FILE I/O
--------
I/O thread 0 state: waiting for i/o request (insert buffer thread)
I/O thread 1 state: waiting for i/o request (log thread)
I/O thread 2 state: waiting for i/o request (read thread)
I/O thread 3 state: waiting for i/o request (write thread)
Pending normal aio reads: 0, aio writes: 0,
 ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
483516 OS file reads, 213643 OS file writes, 22977 OS fsyncs
3 pending preads, 0 pending pwrites
82.24 reads/s, 17566 avg bytes/read, 2.81 writes/s, 1.37 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf for space 0: size 1, free list len 62331, seg size 62333, is empty
Ibuf for space 0: size 1, free list len 62331, seg size 62333,
224 inserts, 224 merged recs, 60 merges
Hash table size 5810587, used cells 472583, node heap has 485 buffer(s)
525.97 hash searches/s, 5176.11 non-hash searches/s
---
LOG
---
Log sequence number 98 23519576
Log flushed up to   98 23408825
Last checkpoint at  98 18164108
0 pending log writes, 0 pending chkp writes
9537 log i/o's done, 1.12 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 1622952210; in additional pool allocated 5754112
Dictionary memory allocated 68568
Buffer pool size   89600
Free buffers       0
Database pages     89115
Modified db pages  2529
Pending reads 4
Pending writes: LRU 0, flush list 0, single page 0
Pages read 1343382, created 147413, written 388687
88.12 reads/s, 0.00 creates/s, 1.75 writes/s
Buffer pool hit rate 999 / 1000
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread process no. 32024, id 1532971952, state: sleeping
Number of rows inserted 19324487, updated 95676, deleted 11595, read 344632805
0.94 inserts/s, 7.06 updates/s, 0.00 deletes/s, 45576.21 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
InnoDB: Error: Row id field is wrong length 4294967295 in index `servers` of table `db/servers`
InnoDB: Field number 4294967295, record:
PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 17; hex 77686f69732e6e616d656261792e636f6d; asc whois.namebay.com;; 1: len 2; hex 0018; asc   ;;

060617 14:51:12InnoDB: Assertion failure in thread 1502407600 in file row0sel.c line 2378
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=131072
max_used_connections=63
max_connections=256
threads_connected=60
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 565245 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x97ce270
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...
Cannot determine thread, fp=0x598cc49c, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81b1877
0xbed888
0x819f0bd
0x8263e62
0x8209659
0x82088a0
0x8208590
0x81fa793
0x81fac87
0x81f7111
0x81c6623
0x82d030a
0x82d005a
0x82d01c9
0x82cdd92
0x82ce516
0x82d97f2
0x81f0d49
0x8212c68
0x81c7f7b
0x81cd288
0x81c4adf
0x81c435e
0x81c3864
0xbe7371
0xb409be
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do 
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x5a151210  is invalid pointer
thd->thread_id=2826
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
pure virtual method called
pure virtual method called
Fatal signal 6 while backtracing
Fatal signal 6 while backtracing
pure virtual method called
pure virtual method called
pure virtual method called
pure virtual method called

           Name: servers
         Engine: InnoDB
        Version: 10
     Row_format: Compact
           Rows: 4373
 Avg_row_length: 59
    Data_length: 262144
Max_data_length: 0
   Index_length: 245760
      Data_free: 0
 Auto_increment: 4938
    Create_time: 2006-06-17 14:47:14
    Update_time: NULL
     Check_time: NULL
      Collation: latin1_swedish_ci
       Checksum: NULL
 Create_options: 
        Comment: InnoDB free: 0 kB
1 row in set (0.08 sec)

CREATE TABLE `servers` (
  `server_id` smallint(5) unsigned NOT NULL AUTO_INCREMENT,
  `server` varchar(80) NOT NULL,
  PRIMARY KEY (`server_id`),
  UNIQUE KEY `server` (`server`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

How to repeat:
I do not have a test case.
[18 Jun 2006 11:39] Jeff C
I am wondering if it's related to either trx_commit or O_DIRECT .. so I'm rebuilding the tables with the new values ....

OLD
innodb_flush_log_at_trx_commit=0
innodb_flush_method=O_DIRECT

NEW
innodb_flush_log_at_trx_commit=1
#innodb_flush_method=O_DIRECT

Perhaps it's related to the O_DIRECT... we will see
[19 Jun 2006 9:25] Valeriy Kravchuk
Thank you for a bug report. This bug looks really similar to bug #20213, already verified but not yet fixed. Do you agree to mark it as a duplicate?
[19 Jun 2006 16:48] Jeff C
Yes, please mark it as a duplicate.  

Does this bug go back to 5.0.22 also?
[19 Jun 2006 17:50] Jeff C
For the record, mine goes down with : engine_condition_pushdown=OFF
[20 Jun 2006 9:54] Valeriy Kravchuk
Duplicate of bug #20213. At least, should be checked again when bug #20213 will be fixed.