Bug #39320 assert btr/btr0pcur.c line 217 -innodb_locks_unsafe_for_binlog or read committed
Submitted: 8 Sep 2008 15:53 Modified: 18 Jun 2010 22:35
Reporter: Shane Bester (Platinum Quality Contributor) Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S1 (Critical)
Version:5.1.15->5.1.32, 6.0.9, 6.0.12 OS:Any
Assigned to: Satya B CPU Architecture:Any
Tags: innodb_locks_unsafe_for_binlog, regression

[8 Sep 2008 15:53] Shane Bester
Description:
innodb assertion with innodb_locks_unsafe_for_binlog=1 and some sequence of insert after trigger, with stored routine, stored functions, and vies. removing
innodb_locks_unsafe_for_binlog fixed the problem.

080829 15:06:43 - mysqld got signal 6 ;080829 15:06:43  InnoDB: Assertion failure in thread 1161070912 in file btr/btr0pcur.c line 217
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.
mysqld(print_stacktrace+0x24)[0x6cb7a4]
mysqld(handle_segfault+0x201)[0x5b44c1]
libpthread.so.0[0x3d8d80de80]
libc.so.6(gsignal+0x35)[0x3d8c830155]
libc.so.6(abort+0x110)[0x3d8c831bf0]
mysqld(btr_pcur_restore_position+0x3c9)
mysqld(row_unlock_for_mysql+0x1ea)
mysqld[0x612b4c]
mysqld(sub_select
mysqld[0x612b0c]
mysqld(sub_select
mysqld[0x612781]
mysqld(JOIN::exec()
mysqld(mysql_select
mysqld(handle_select
mysqld(mysql_execute_command
mysqld(sp_instr_stmt::exec_core
mysqld(sp_lex_keeper::reset_lex_and_exec_core
mysqld(sp_instr_stmt::execute
mysqld(sp_head::execute(THD*)+0x363)
mysqld(sp_head::execute_procedure
mysqld(mysql_execute_command
mysqld(sp_instr_stmt::exec_core
mysqld(sp_lex_keeper::reset_lex_and_exec_core
mysqld(sp_instr_stmt::execute
mysqld(sp_head::execute
mysqld(sp_head::execute_procedure
mysqld(mysql_execute_command
mysqld(sp_instr_stmt::exec_core
mysqld(sp_lex_keeper::reset_lex_and_exec_core
mysqld(sp_instr_stmt::execute
mysqld(sp_head::execute
mysqld(sp_head::execute_trigger
mysqld(Table_triggers_list::process_triggers
mysqld(write_record
mysqld(mysql_insert
mysqld(mysql_execute_command
mysqld(mysql_parse
mysqld(dispatch_command
mysqld(do_command
mysqld(handle_one_connection+0x11d)

How to repeat:
run mysqld with --innodb_locks_unsafe_for_binlog=1
No known testcase.
Generic flow of the crashing code was this: (see private note for actual names)

1) somebody insert a record into `t1` table
2) after insert trigger (`t1_after_insert_trigger`) is invoked
3) trigger calls sp `sp1`
4) that sp calls another sp `sp2`
5) this sp does REPLACE INTO .. SELECT .. FROM <big view>:
6) this view is a join of 6 tables including a stored function call in one join condition
[8 Sep 2008 15:59] MySQL Verification Team
btr/btr0pcur.c line 217 looks like this:
index = btr_cur_get_index(btr_pcur_get_btr_cur(cursor));

if (UNIV_UNLIKELY(cursor->old_stored != BTR_PCUR_OLD_STORED)
   || UNIV_UNLIKELY(cursor->pos_state != BTR_PCUR_WAS_POSITIONED
     && cursor->pos_state != BTR_PCUR_IS_POSITIONED)) {
ut_print_buf(stderr, cursor, sizeof(btr_pcur_t));
if (cursor->trx_if_known) {
	trx_print(stderr, cursor->trx_if_known, 0);
}
ut_error;
}
[8 Sep 2008 19:19] MySQL Verification Team
I analyzed the hex output of cursor values leading to the assertion, here's the values for each field:

cursor->btr_cur.index      =  b8c45bb8aa2a0000                 
cursor->btr_cur.page_cur   =  ac4922c7aa2a0000                 
cursor->btr_cur.left_page  =  0000000000000000                 
cursor->btr_cur.thr        =  0000000000000000                 
cursor->btr_cur.flag       =  0300000000000000 (BTR_CUR_BINARY)
cursor->btr_cur.tree_height=  0300000000000000                 
cursor->btr_cur.up_match   =  0000000000000000                 
cursor->btr_cur.up_bytes   =  0300000000000000                 
cursor->btr_cur.low_match  =  0100000000000000                 
cursor->btr_cur.low_bytes  =  0000000000000000                 
cursor->btr_cur.n_fields   =  0000000000000000                 
cursor->btr_cur.n_bytes    =  0000000000000000                 
cursor->btr_cur.fold       =  0000000000000000                 
cursor->btr_cur.path_arr   =  0000000000000000                 
cursor->latch_mode         =  0100000000000000                 
cursor->old_stored         =  8344510700000000                 
cursor->old_rec            =  0000000000000000                 
cursor->old_n_field        =  0000000000000000                 
cursor->rel_pos            =  0000000000000000                 
cursor->block_when_stored  =  0000000000000000                 
cursor->modify_clock       =  00000000000000000000000000000000 
cursor->pos_state          =  60e1117700000000                 
cursor->search_mode        =  0400000000000000                 
cursor->trx_if_known*      =  b87027b9aa2a0000                 
cursor->mtr*               =  0000000000000000                 
cursor->old_rec_buf*       =  0000000000000000                 
cursor->buf_size           =  0000000000000000  

as we see, cursor->pos_state is BTR_PCUR_IS_POSITIONED.   
cursor->old_stored is BTR_PCUR_OLD_NOT_STORED.  This is a problem I think.
[9 Sep 2008 4:37] Valeriy Kravchuk
Looks similar to bug #15650. I am not sure that patch for that bug is included into 5.1...
[27 Jan 2009 17:45] Andrii Nikitin
I've checked fix for bug #15650, it is in 5.1 also
[25 Feb 2009 22:50] MySQL Verification Team
TESTCASE:
---------

drop table if exists `t1`,`t2`;
create table `t1` (`a` int, `b` int) engine=innodb;
create table `t2` (`c` int,  `d` int, key `c` (`c`)) engine=innodb;
insert into `t1` values (1,1);
insert into `t2` values (1,2);
delete from `t1` using `t1` join `t2` on `t1`.`a` = `t2`.`c` where `t2`.`d` in (1);
[26 Feb 2009 7:01] Valeriy Kravchuk
5.0.74 works as expected, so this is a regression that may prevent successful upgrade to 5.1.
[26 Feb 2009 8:36] Marko Mäkelä
I can reproduce it with
innodb_locks_unsafe_for_binlog=1
but not with
set transaction isolation level read committed;
even though the two should be equivalent.

This is related to semi-consistent reads. Unlocking the clustered index record of t2 will fail, probably because the clustered index of t2 wasn't needed in the lookup in the first place.

I don't know if a semi-consistent read should be attempted for t2 at all, since that table is only read by the DELETE statement. See Bug #43160.
[26 Feb 2009 23:28] Laine Campbell
This still has not been fixed in 5.1.31.  

centos: 2.6.18-53.el5 #1 SMP Mon Nov 12 02:14:55 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
Server version: 5.1.26-rc-log MySQL Community Server (GPL)
(also tested in .31 with identical results)

Error log:

 hex b8c015dbaa2a00009aa705deaa2a00000000000000000000000000000000000002000000000000000300000000000000000000000000000007000000000000000100000000000000000000000000000001000000000000000000000000000000fe688022852cd2ad00000000000000000100000000000000834451070000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000060e11177000000000400000000000000b88015dbaa2a0000000000000000000000000000000000000000000000000000; asc      *       *                                                                                   h " ,                   DQ                                                     `  w                 *                          ;TRANSACTION 0 1498368, ACTIVE 0 sec, process no 31351, OS thread id 1159788864 unlock_row, thread declared inside InnoDB 255
mysql tables in use 3, locked 3
1651 lock struct(s), heap size 161776, 99265 row lock(s)
MySQL thread id 7, query id 41 localhost root Sending data
DELETE ft FROM agg_c_group_keyword_instance_fact_21_60 ft, ( SELECT sub.a FROM    ( SELECT DISTINCT(publisher_group_id) as a      FROM agg_c_group_keyword_instance_fact_21_60    ) sub    LEFT JOIN keyword_instance_dim_21_60 dimTable    ON sub.a = dimTable.publisher_group_id    WHERE ( dimTable.client_account_id in (163) ) ) b WHERE ft.publisher_group_id = b.a
090226 22:16:55  InnoDB: Assertion failure in thread 1159788864 in file btr/btr0pcur.c line 217
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.
/usr/local/mysql/bin/mysqld(my_print_stacktrace+0x2e)[0x89b4be]
/usr/local/mysql/bin/mysqld(handle_segfault+0x322)[0x5d29f2]
/lib64/libpthread.so.0[0x31f800de70]
/lib64/libc.so.6(gsignal+0x35)[0x31f7430055]
/lib64/libc.so.6(abort+0x110)[0x31f7431af0]
/usr/local/mysql/bin/mysqld(btr_pcur_restore_position+0x93)[0x829d83]
/usr/local/mysql/bin/mysqld(row_unlock_for_mysql+0x21b)[0x7e8b1b]
/usr/local/mysql/bin/mysqld[0x62cca4]
/usr/local/mysql/bin/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x78)[0x632078]
/usr/local/mysql/bin/mysqld[0x62cc25]
/usr/local/mysql/bin/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x96)[0x632096]
/usr/local/mysql/bin/mysqld[0x6349f5]
/usr/local/mysql/bin/mysqld(_ZN4JOIN4execEv+0x936)[0x64af76]
/usr/local/mysql/bin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x124)[0x646ff4]
/usr/local/mysql/bin/mysqld(_Z21mysql_derived_fillingP3THDP6st_lexP10TABLE_LIST+0x117)[0x712137]
/usr/local/mysql/bin/mysqld(_Z20mysql_handle_derivedP6st_lexPFbP3THDS0_P10TABLE_LISTE+0x6a)[0x711faa]
/usr/local/mysql/bin/mysqld(_Z28open_and_lock_tables_derivedP3THDP10TABLE_LISTb+0x156)[0x61db46]
/usr/local/mysql/bin/mysqld(_Z21mysql_execute_commandP3THD+0x4ae8)[0x5e7518]
/usr/local/mysql/bin/mysqld(_Z11mysql_parseP3THDPKcjPS2_+0x357)[0x5e8297]
/usr/local/mysql/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0xe63)[0x5e9103]
/usr/local/mysql/bin/mysqld(_Z10do_commandP3THD+0xe6)[0x5e99c6]
/usr/local/mysql/bin/mysqld(handle_one_connection+0x236)[0x5dc636]
/lib64/libpthread.so.0[0x31f80062f7]
/lib64/libc.so.6(clone+0x6d)[0x31f74ce85d]
090226 22:16:55 - 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=536870912
read_buffer_size=8388608
max_used_connections=5
max_threads=1000
threads_connected=5
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 16918452 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x6a99740
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 = 0x4520f100 thread_stack 0x40000
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x6aa47b0 = DELETE ft FROM agg_c_group_keyword_instance_fact_21_60 ft, ( SELECT sub.a FROM    ( SELECT DISTINCT(publisher_group_id) as a      FROM agg_c_group_keyword_instance_fact_21_60    ) sub    LEFT JOIN keyword_instance_dim_21_60 dimTable    ON sub.a = dimTable.publisher_group_id    WHERE ( dimTable.client_account_id in (163) ) ) b WHERE ft.publisher_group_id = b.a
thd->thread_id=7
thd->killed=NOT_KILLED

my.cnf
[client]
port            = 3306
socket          = /tmp/mysql.sock
[mysqld]
server-id       = 1004
port            = 3306
socket          = /tmp/mysql.sock
basedir         = /usr/local/mysql
datadir         = /usr/local/mysql/data
init_connect    = 'SET NAMES utf8'
max_connections    = 1000
max_connect_errors = 10
max_allowed_packet = 8M
skip-locking
log-bin            = /var/log/mysql/mysql-bin
binlog_cache_size  = 1M
max_binlog_size    = 1G
expire_logs_days   = 10
binlog-ignore-db = test
log-queries-not-using-indexes
log-slow-queries   = /var/log/mysql/xxxxx-slow-query.log
log-error          = /var/log/mysql/xxxxx-error.log
long_query_time    = 10
log-warnings       = 2
sync_binlog        = 1
table_cache       = 4096
thread_cache_size = 8
query_cache_size  = 256M
query_cache_limit = 4M
local_infile = 1
key_buffer_size         = 512M
myisam_sort_buffer_size = 64M
myisam_recover
innodb_data_home_dir      = /usr/local/mysql/data/
innodb_data_file_path     = ibdata1:10M:autoextend
innodb_log_group_home_dir = /usr/local/mysql/data/
innodb_buffer_pool_size   = 1G
innodb_additional_mem_pool_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 400
innodb_file_per_table
innodb_locks_unsafe_for_binlog = 0
innodb_thread_concurrency = 20
sort_buffer_size     = 8M
read_buffer_size     = 8M
read_rnd_buffer_size = 8M
join_buffer_size     = 16M
log-slave-updates
relay-log           = /var/log/mysql/xxxxxxxx-relay
relay-log-info-file = /var/log/mysql/xxxxxxxx-relay-log.info
relay-log-index     = /var/log/mysql/xxxxxxxx-relay-log.index
slave_transaction_retries = 60
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
[isamchk]
key_buffer = 128M
sort_buffer_size = 128M
read_buffer = 32M
write_buffer = 32M
[myisamchk]
key_buffer = 128M
sort_buffer_size = 128M
read_buffer = 32M
write_buffer = 32M
[mysqlhotcopy]
interactive-timeout
[27 Feb 2009 12:40] Marko Mäkelä
Nobody claimed that the bug had been fixed.  I said that I can't reproduce with the READ COMMITTED isolation level, but that was because I did not realize that the isolation level is reset in autocommit mode.  An explicit BEGIN helps:

drop table if exists t1,t2;
create table t1 (a int, b int) engine=innodb;
create table t2 (c int, d int, key (c)) engine=innodb;
begin;
set session transaction isolation level read committed;
insert into t1 values (1,1);
insert into t2 values (1,2);
delete from t1 using t1 join t2 on t1.a = t2.c where t2.d in (1);
commit;

The DELETE statement will crash.  The crash will occur even if t1 is defined as a MyISAM table.
[6 Mar 2009 14:25] Marko Mäkelä
Fix: row_sel_get_clust_rec_for_mysql() should store the cursor position for unlock_row().
[12 Mar 2009 14:21] River Tarnell
Where can I find the patch?
[16 Mar 2009 14:17] Jason Galloway
Could someone let me know where to find the patch?
[19 Mar 2009 15:49] Calvin Sun
Patch for bug#39320

Attachment: r4399.patch (text/x-patch), 1.77 KiB.

[15 Apr 2009 11:46] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/72144

2858 Satya B	2009-04-15
      Applying InnoDB snashot 5.1-ss4699, part 1. Fixes BUG#39320 and other
      problems
      
      1) BUG#39320 - innodb crash in file btr/btr0pcur.c line 217 with 
                     innodb_locks_unsafe_for_binlog
      
      2) Fixes bug in multi-table semi consistent reads.
      
      3) Fixes email address from dev@innodb.com to innodb_dev_ww@oracle.com
      
      4) Fixes warning message generated by main.innodb test
      
      
      Detailed revision comments:
      
      r4399 | marko | 2009-03-12 09:38:05 +0200 (Thu, 12 Mar 2009) | 5 lines
      branches/5.1: row_sel_get_clust_rec_for_mysql(): Store the cursor position
      also for unlock_row().  (Bug #39320)
      
      rb://96 approved by Heikki Tuuri.
      
      r4400 | marko | 2009-03-12 10:06:44 +0200 (Thu, 12 Mar 2009) | 8 lines
      branches/5.1: Fix a bug in multi-table semi-consistent reads.
      Remember the acquired record locks per table handle (row_prebuilt_t)
      rather than per transaction (trx_t), so that unlock_row should successfully
      unlock all non-matching rows in multi-table operations.
      This deficiency was found while investigating Bug #39320.
      
      rb://94 approved by Heikki Tuuri.
      
      r4481 | marko | 2009-03-19 15:01:48 +0200 (Thu, 19 Mar 2009) | 6 lines
      branches/5.1: row_unlock_for_mysql(): Do not unlock records that were
      modified by the current transaction.  This bug was introduced or unmasked
      in r4400.
      
      rb://97 approved by Heikki Tuuri
      
      r4573 | vasil | 2009-03-30 14:17:13 +0300 (Mon, 30 Mar 2009) | 4 lines
      branches/5.1:
      
      Fix email address from dev@innodb.com to innodb_dev_ww@oracle.com
      
      r4574 | vasil | 2009-03-30 14:27:08 +0300 (Mon, 30 Mar 2009) | 38 lines
      branches/5.1:
      
      Restore the state of INNODB_THREAD_CONCURRENCY to silence this warning:
      
        TEST                                      RESULT   TIME (ms)
        ------------------------------------------------------------
        
        worker[1] Using MTR_BUILD_THREAD 250, with reserved ports 12500..12509
        main.innodb                              [ pass ]   8803
        
        MTR's internal check of the test case 'main.innodb' failed.
        This means that the test case does not preserve the state that existed
        before the test case was executed.  Most likely the test case did not
        do a proper clean-up.
        This is the diff of the states of the servers before and after the
        test case was executed:
        mysqltest: Logging to '/tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.log'.
        mysqltest: Results saved in '/tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.result'.
        mysqltest: Connecting to server localhost:12500 (socket /tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/mysqld.1.sock) as 'root', connection 'default', attempt 0 ...
        mysqltest: ... Connected.
        mysqltest: Start processing test commands from './include/check-testcase.test' ...
        mysqltest: ... Done processing test commands.
        --- /tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.result	2009-03-30 14:12:31.000000000 +0300
        +++ /tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.reject	2009-03-30 14:12:41.000000000 +0300
        @@ -99,7 +99,7 @@
         INNODB_SUPPORT_XA	ON
         INNODB_SYNC_SPIN_LOOPS	20
         INNODB_TABLE_LOCKS	ON
        -INNODB_THREAD_CONCURRENCY	8
        +INNODB_THREAD_CONCURRENCY	16
         INNODB_THREAD_SLEEP_DELAY	10000
         INSERT_ID	0
         INTERACTIVE_TIMEOUT	28800
        
        mysqltest: Result content mismatch
        
        not ok
      
      r4576 | vasil | 2009-03-30 16:25:10 +0300 (Mon, 30 Mar 2009) | 4 lines
      branches/5.1:
      
      Revert a change to Makefile.am that I committed accidentally in c4574.
      modified:
        mysql-test/r/innodb-semi-consistent.result
        mysql-test/t/innodb-semi-consistent.test
        mysql-test/t/innodb.test
        storage/innobase/include/row0mysql.h
        storage/innobase/include/trx0trx.h
        storage/innobase/include/trx0trx.ic
        storage/innobase/lock/lock0lock.c
        storage/innobase/row/row0mysql.c
        storage/innobase/row/row0sel.c
        storage/innobase/trx/trx0trx.c
[20 Apr 2009 6:59] Satya B
Notes to Docs team:
Patch queued to 5.1-bugteam.  NOT yet in 6.0 (5.1-snapshot-ss4699 is null merged into 6.0).
Please return to "Patch approved" after documenting until 6.0 snapshot is available.
[27 Apr 2009 20:51] Daniel Bakken
This bug is also present in MySQL 5.4-beta:

OS: Solaris 10

 len 224; hex f8d8bba203000000ecac9fb900000000010000000000000000069ba20300000003000000000000000300000000000000020000000000000003000000000000000300000000000000000000000000000004000000000000000100000000000000050000800000000008000000000000000100000000000000834451070000000000000000000000000000000000000000000000000000000000000000000000000000000000100000f0e60a010000000060e11177000000000400000000000000785799a2030000000000000000000000000000000000000099e3e380da8c67bc; asc                                                                                                                          DQ                                                     `  w            xW                            g ;TRANSACTION 0 681031276, ACTIVE 7 sec, OS thread id 40 unlock_row, thread declared inside InnoDB 475
mysql tables in use 3, locked 3
1097 lock struct(s), heap size 145392, 175932 row lock(s)
MySQL thread id 728, query id 247110 fafnir.ccb 192.168.5.22 mackerman Copying to tmp table
REPLACE INTO reis_final.reis_final_beta12407199685
                        select b.CountyID, b.IndID, b.Year, b.Emp,
                          IF(b.Earn/b.Emp < x.blimit, (x.blimit * b.Emp),
                            IF(b.Earn/b.Emp > x.ulimit, (x.ulimit * b.Emp),
                              b.Earn)) as Earn
                        from reis_final.reis_final_beta12407199685 b
                        INNER JOIN ind_definition.naics_2002_to_reis_6digit map ON b.IndID = map.IndID
                        INNER JOIN
                          (
                          select lineid, max(earn/emp) as ulimit, min(earn/emp) as blimit
                          from reis_final.reis_final_alpha where emp > 10 and year = 2006
                          GROUP BY LineID, Year
                          ) AS x ON x.LineID = map.reis
                        WHERE b.Year = 2006 AND b.Emp != 0
090425 23:28:06  InnoDB: Assertion failure in thread 40 in file btr/btr0pcur.c line 217
[5 May 2009 19:38] Bugs System
Pushed into 5.1.35 (revid:davi.arnaut@sun.com-20090505190206-9xmh7dlc6kom8exp) (version source revid:davi.arnaut@sun.com-20090505190206-9xmh7dlc6kom8exp) (merge vers: 5.1.35) (pib:6)
[6 May 2009 14:11] Bugs System
Pushed into 6.0.12-alpha (revid:svoj@sun.com-20090506125450-yokcmvqf2g7jhujq) (version source revid:satya.bn@sun.com-20090415130616-z1o0xrb1lv340ser) (merge vers: 6.0.11-alpha) (pib:6)
[13 May 2009 23:24] Paul DuBois
Noted in 5.1.35, 6.0.12 changelogs.

In an UPDATE or DELETE via a secondary index, InnoDB did not store
the cursor position. This made InnoDB crash in semi-consistent read
while attempting to unlock a non-matching record.
[19 May 2009 20:03] MySQL Verification Team
See bug: http://bugs.mysql.com/bug.php?id=44959.
[19 May 2009 20:08] MySQL Verification Team
Bug: http://bugs.mysql.com/bug.php?id=44959 was marked as duplicate of this one.
[21 May 2009 13:10] MySQL Verification Team
bug #45007 is a duplicate of this
[15 Jun 2009 8:25] Bugs System
Pushed into 5.1.35-ndb-6.3.26 (revid:jonas@mysql.com-20090615074202-0r5r2jmi83tww6sf) (version source revid:jonas@mysql.com-20090615070837-9pccutgc7repvb4d) (merge vers: 5.1.35-ndb-6.3.26) (pib:6)
[15 Jun 2009 9:05] Bugs System
Pushed into 5.1.35-ndb-7.0.7 (revid:jonas@mysql.com-20090615074335-9hcltksp5cu5fucn) (version source revid:jonas@mysql.com-20090615072714-rmfkvrbbipd9r32c) (merge vers: 5.1.35-ndb-7.0.7) (pib:6)
[15 Jun 2009 9:45] Bugs System
Pushed into 5.1.35-ndb-6.2.19 (revid:jonas@mysql.com-20090615061520-sq7ds4yw299ggugm) (version source revid:jonas@mysql.com-20090615054654-ebgpz7elwu1xj36j) (merge vers: 5.1.35-ndb-6.2.19) (pib:6)
[8 Jul 2009 13:30] Bugs System
Pushed into 5.1.37 (revid:joro@sun.com-20090708131116-kyz8iotbum8w9yic) (version source revid:joro@sun.com-20090622115751-e2946ixgjf73narz) (merge vers: 5.1.37) (pib:11)
[9 Jul 2009 7:36] Bugs System
Pushed into 5.1.37 (revid:joro@sun.com-20090708131116-kyz8iotbum8w9yic) (version source revid:joro@sun.com-20090622115751-e2946ixgjf73narz) (merge vers: 5.1.37) (pib:11)
[10 Jul 2009 11:21] Bugs System
Pushed into 5.4.4-alpha (revid:anozdrin@bk-internal.mysql.com-20090710111017-bnh2cau84ug1hvei) (version source revid:satya.bn@sun.com-20090622113236-j8cc6krsju4qe1iq) (merge vers: 5.4.4-alpha) (pib:11)
[10 Jul 2009 23:19] Bugs System
Pushed into 5.1.37 (revid:build@mysql.com-20090710231213-9guqdu0avc0uwdkp) (version source revid:build@mysql.com-20090710231213-9guqdu0avc0uwdkp) (merge vers: 5.1.37) (pib:11)
[23 Jul 2009 10:24] Bugs System
Pushed into 5.4.4-alpha (revid:alik@sun.com-20090723102221-ps4uaphwbxzj8p0q) (version source revid:joerg@mysql.com-20090721145751-rqqnhv0kage18wfi) (merge vers: 5.4.4-alpha) (pib:11)
[3 Aug 2009 12:29] MySQL Verification Team
Bug http://bugs.mysql.com/bug.php?id=45302 marked as duplicate of this one.
[11 Aug 2009 11:21] MySQL Verification Team
See bug: http://bugs.mysql.com/bug.php?id=46647.
[26 Aug 2009 13:46] Bugs System
Pushed into 5.1.37-ndb-7.0.8 (revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (version source revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (merge vers: 5.1.37-ndb-7.0.8) (pib:11)
[26 Aug 2009 13:46] Bugs System
Pushed into 5.1.37-ndb-6.3.27 (revid:jonas@mysql.com-20090826105955-bkj027t47gfbamnc) (version source revid:jonas@mysql.com-20090826105955-bkj027t47gfbamnc) (merge vers: 5.1.37-ndb-6.3.27) (pib:11)
[26 Aug 2009 13:48] Bugs System
Pushed into 5.1.37-ndb-6.2.19 (revid:jonas@mysql.com-20090825194404-37rtosk049t9koc4) (version source revid:jonas@mysql.com-20090825194404-37rtosk049t9koc4) (merge vers: 5.1.37-ndb-6.2.19) (pib:11)
[27 Aug 2009 16:33] Bugs System
Pushed into 5.1.35-ndb-7.1.0 (revid:magnus.blaudd@sun.com-20090827163030-6o3kk6r2oua159hr) (version source revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (merge vers: 5.1.37-ndb-7.0.8) (pib:11)
[5 May 2010 15:22] Bugs System
Pushed into 5.1.47 (revid:joro@sun.com-20100505145753-ivlt4hclbrjy8eye) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[6 May 2010 7:29] Roel Van de Paar
"Pushed into 5.1.37" > Closed > "Pushed into 5.1.47" > Documenting

Could someone clarify what is happening here?

Is the patch in 5.1.37?
[6 May 2010 16:02] Paul DuBois
Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.
[28 May 2010 6:13] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100524190136-egaq7e8zgkwb9aqi) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (pib:16)
[28 May 2010 6:41] Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100524190941-nuudpx60if25wsvx) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[28 May 2010 7:09] Bugs System
Pushed into 5.5.5-m3 (revid:alik@sun.com-20100524185725-c8k5q7v60i5nix3t) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[29 May 2010 2:52] Paul DuBois
Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.
[15 Jun 2010 8:18] Bugs System
Pushed into 5.5.5-m3 (revid:alik@sun.com-20100615080459-smuswd9ooeywcxuc) (version source revid:mmakela@bk-internal.mysql.com-20100415070122-1nxji8ym4mao13ao) (merge vers: 5.1.47) (pib:16)
[15 Jun 2010 8:35] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100615080558-cw01bzdqr1bdmmec) (version source revid:mmakela@bk-internal.mysql.com-20100415070122-1nxji8ym4mao13ao) (pib:16)
[17 Jun 2010 12:20] Bugs System
Pushed into 5.1.47-ndb-7.0.16 (revid:martin.skold@mysql.com-20100617114014-bva0dy24yyd67697) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[17 Jun 2010 13:07] Bugs System
Pushed into 5.1.47-ndb-6.2.19 (revid:martin.skold@mysql.com-20100617115448-idrbic6gbki37h1c) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[17 Jun 2010 13:48] Bugs System
Pushed into 5.1.47-ndb-6.3.35 (revid:martin.skold@mysql.com-20100617114611-61aqbb52j752y116) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[4 Dec 2010 12:44] huang shuhuai
“Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.”

what are these means? is the bug fixed or not?
i encouter this bug too.
[5 Dec 2010 8:48] James Day
There's sometimes a lot of "noise" in the commit messages due to the number of source code trees and versions we maintain, with a message being generated each time something is added to each version. Here's the important bit:

 ----------

[14 May 2009 1:24] Paul DuBois

Noted in 5.1.35, 6.0.12 changelogs.

In an UPDATE or DELETE via a secondary index, InnoDB did not store
the cursor position. This made InnoDB crash in semi-consistent read
while attempting to unlock a non-matching record.

 ----------

It'll also be in 5.5 even though that isn't mentioned because of the age of the message.