MySQL Bugs: #19834: Using cursors when running in READ-COMMITTED can cause InnoDB to crash

Bug #19834	Using cursors when running in READ-COMMITTED can cause InnoDB to crash
Submitted:	15 May 2006 23:29	Modified:	18 Jun 2010 12:44
Reporter:	Steve DeWitt	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S1 (Critical)
Version:	5.0.21, 5.0.20a,5.0.22,5.0.23,5.0.24a	OS:	Linux (RedHat Enterprise 4)
Assigned to:	Marko Mäkelä	CPU Architecture:	Any

Description:
run update statement on table and a BEFORE trigger fires. This causes the database to restart. Without the trigger the update statement works fine. The trigger tries to update a decimal field.

How to repeat:
execute update statement:
update fin_billing_rate set effective_thru_period = 200511 where emp_nbr = '00779801' and effective_from_period = 200512

database restarts if triggers are defined on table fin_billing_rate

just to add, I ran the ALTER TABLE tablename FORCE for all the tables that were indicated int he .err file. I also ran a mysqlcheck with --check-upgrade --auto-repair

Thank you for a problem report. Please, try to repeat with a newer version, 5.0.21. In case of the same crash, send the resolvedstack traces. Also, please, send the SHOW CREATE TABLE, SHOW TABLE STATUS results for the problematic table, fin_billing_rate, and the CREATE TRIGGER statement used for that BEFORE trigger.

I was able to re-create the error:
1) create new db in 5.0.20a
2) create tables that are used for update and trigger
3) create triggers
4) import data
5) run update

server restarted:
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=402653184
read_buffer_size=2093056
max_used_connections=1
max_connections=100
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8aac448
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=0x9900256c, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x816692c
0xfbffd420
(nil)
0x821b2e3
0x8210d18
0x8210be2
0x820325b
0x8203c88
0x820ab5d
0x81d28dd
0x817fe13
0x8183130
0x818388f
0x8184648
0x8184ca4
0x483e7371
0x482e89be
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 0x8ad3de8 = update fin_billing_rate set effective_thru_period = 200511 where emp_nbr = '0
0779801' and effective_from_period = 200512
thd->thread_id=1
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.

Number of processes running now: 0
060516 08:28:46 mysqld restarted
060516 8:28:47 InnoDB: Database was not shut down normally!
/
...skipping
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
060516 8:28:47 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 3348629692.
InnoDB: Doing recovery: scanned up to log sequence number 0 3348629692
InnoDB: Last MySQL binlog file position 0 117364958, file name ./mysql-bin.000447
060516 8:28:47 InnoDB: Started; log sequence number 0 3348629692
060516 8:28:47 [Note] Recovering after a crash using mysql-bin
060516 8:28:47 [Note] Starting crash recovery...
060516 8:28:47 [Note] Crash recovery finished.
060516 8:28:47 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.20a-standard-log' socket: '/tmp/mysql5-3311.sock' port: 3311 MySQL Community Edition -
Standard (GPL)

I will upgrade to 5.0.21

We have upgraded to 5.0.21, without stripped binaries and with --with-debug enabled.  We still have the same issue.

Here is the stack trace:

0x816867c handle_segfault + 636
0xfbffd420 _end + -207192496
0x99002950 _end + -1868115072
0x821d7c3 _ZN11ha_innobase13general_fetchEPcjj + 83
0x8213718 _ZN7handler15read_range_nextEv + 56
0x82135e2 _ZN7handler21read_multi_range_nextEPP18st_key_multi_range + 34
0x8205e9b _ZN18QUICK_RANGE_SELECT8get_nextEv + 331
0x82068c8 _ZN26QUICK_ROR_INTERSECT_SELECT8get_nextEv + 216
0x820d55d _Z8rr_quickP14st_read_record + 29
0x81d535d _Z12mysql_updateP3THDP13st_table_listR4ListI4ItemES6_PS4_jP8st_orderm15enum_duplicatesb + 2269
0x81823c3 _Z21mysql_execute_commandP3THD + 16579
0x81856b0 _Z11mysql_parseP3THDPcj + 320
0x8185e3e _Z16dispatch_command19enum_server_commandP3THDPcj + 1678
0x8186bf8 _Z10do_commandP3THD + 136
0x81872e4 handle_one_connection + 1492
0x483e7371 _end + 1071979937
0x482e89be _end + 1070937070

OK, the crash is repeatable. But how can I repeat it without a test case? Please, send the SHOW CREATE TABLE, SHOW TABLE STATUS results for the problematic table, fin_billing_rate, and the CREATE TRIGGER statement used for that BEFORE trigger. Alternatively, can you just upload the dump of the related database objects? You can send all the above as private comment/file, if you want.

this is the data

Attachment: data.zip (application/zip, text), 8.54 KiB.

Test case:
run the following query after creating tables and triggers
update fin_billing_rate set effective_thru_period = 200601 where emp_nbr = '00779801' and effective_from_period = 200512

this is what we have been doing and it is in the first file I uploaded.

I was unable to repeat on Suse Linux 10 with current source server:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 15 to server version: 5.0.22-debug

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> update fin_billing_rate set effective_thru_period = 200601 where emp_nbr =
    -> '00779801' and effective_from_period = 200512;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select version();
+--------------+
| version()    |
+--------------+
| 5.0.22-debug | 
+--------------+
1 row in set (0.00 sec)

FYI,
we use our own build so we decided to test this against the binary rpm for redhat enterprise 4 and got the same errors(restarted the mysql server). We also tested this on a Zen server, running on redhat enterprise 4, with the same result(restarted the mysql server). Finally We tested this on the Windows versions and that works fine. Windows versions 5.0.20-nt and 5.0.21-community-nt on windows XP professional.

So, the bug is surely not repeatable in 5.0.22 (according to Miguel's test). Please, wait for 5.0.22 to be officially released and, if you will be able to repeat the crash on any plaform, reopen this bug report.

this issue seems to be resolved in 5.0.22. We have run the same tests that caused the crash and it is fixed. I wonder though if this should have at least been classified as a bug, for versions 5.0.20a and 5.0.21, rather than "Can't repeat". Is it standard practice to assign that status when it can't be repeated in some nightly build but can be in a GA release?

Verified:

mysql> call updatefinbillingratetest();
ERROR 2013 (HY000): Lost connection to MySQL server during query

[root@net-sup1 csc10417]# /tmp/mysql5.0.23/bin/resolve_stack_dump -s net-sup1.sym -n net-sup1.stack
0x817b8d2 handle_segfault + 368
0x8687c8 (?)
0x83a3d7f alloc_root + 444
0x82354f1 _ZN11ha_innobase13general_fetchEPcjj + 101
0x82355e7 _ZN11ha_innobase15index_next_sameEPcPKcj + 47
0x822b8ea _ZN7handler15read_range_nextEv + 110
0x822b646 _ZN7handler21read_multi_range_nextEPP18st_key_multi_range + 104
0x821d06c _ZN18QUICK_RANGE_SELECT8get_nextEv + 230
0x821c9e4 _ZN26QUICK_ROR_INTERSECT_SELECT8get_nextEv + 324
0x82246b0 _Z8rr_quickP14st_read_record + 86
0x81e8cf8 _Z12mysql_updateP3THDP13st_table_listR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesb + 3900
0x819307f _Z21mysql_execute_commandP3THD + 7919
0x828eee6 _ZN13sp_instr_stmt9exec_coreEP3THDPj + 14
0x828ec2b _ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr + 331
0x828edc6 _ZN13sp_instr_stmt7executeEP3THDPj + 224
0x828bff3 _ZN7sp_head7executeEP3THD + 1261
0x828cfd0 _ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE + 1032
0x81958ea _Z21mysql_execute_commandP3THD + 18266
0x819836e _Z11mysql_parseP3THDPcj + 312
0x818febe _Z16dispatch_command19enum_server_commandP3THDPcj + 1620
0x818f85f _Z10do_commandP3THD + 437
0x818ebce handle_one_connection + 768
0x862341 (?)
0x7bb6fe (?)

Further testing shows that this is a problem with the READ-COMMITTED transaction isolation level of InnoDB:

mysql> select @@tx_isolation;
+----------------+
| @@tx_isolation |
+----------------+
| READ-COMMITTED |
+----------------+
1 row in set (0.00 sec)

mysql> call updatefinbillingratetest();
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql> 
mysql> exit
Bye

..restart..

[root@net-sup1 mleith]# mysql -u root -S /tmp/mysql5-3311.sock 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.0.23-debug-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> select @@tx_isolation;
+----------------+
| @@tx_isolation |
+----------------+
| READ-COMMITTED |
+----------------+
1 row in set (0.00 sec)

mysql> set session tx_isolation = 'REPEATABLE-READ';
Query OK, 0 rows affected (0.00 sec)

mysql> select @@tx_isolation;
+-----------------+
| @@tx_isolation  |
+-----------------+
| REPEATABLE-READ |
+-----------------+
1 row in set (0.00 sec)

mysql> use test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> call updatefinbillingratetest();

..still running..

Updated bug details

Hi!

I am not able to repeat this on 5.0.22. But I am not sure that I set up the test in the right way.

Please make a self-contained dump of pure SQL statements that repeats this crash. A dump such that simply piping it to the mysql client makes mysqld to crash.

Based on the stack trace, my guess is that in the multi-range search there is some bug in MySQL or in the the way it calls InnoDB's interface functions. Since the query optimization can differ, it is no wonder that I cannot repeat this right now.

Regards,

Heikki

Great, I will let you guys hammer this out. I have supplied MySQL with plenty of sql, ddl, data to reproduce this issue.
thanks

Mark,

I cannot repeat this with 5.0.23 (downloaded from ftp.sunsite.dk).

Please make a self-contained SQL file, or give us access to the machine where you can repeat this.

--Heikki

mysql> load data infile '/home/heikki/bugs/finbillingrate' into table fin_billing_rate;
Query OK, 3 rows affected (0.00 sec)
Records: 3  Deleted: 0  Skipped: 0  Warnings: 0

mysql> load data infile '/home/heikki/bugs/mwlogactivity' into table mw_log_activity;
Query OK, 100 rows affected (0.01 sec)
Records: 100  Deleted: 0  Skipped: 0  Warnings: 0

mysql> load data infile '/home/heikki/bugs/mwlogactivitydesc' into table mw_log_activity_desc;
Query OK, 6 rows affected (0.01 sec)
Records: 6  Deleted: 0  Skipped: 0  Warnings: 0

mysql> load data infile '/home/heikki/bugs/fin_practice' into table fin_practice;
ERROR 13 (HY000): Can't get stat of '/home/heikki/bugs/fin_practice' (Errcode: 2)
mysql> load data infile '/home/heikki/bugs/finpractice' into table fin_practice;
Query OK, 154 rows affected (0.01 sec)
Records: 154  Deleted: 0  Skipped: 0  Warnings: 0

mysql> load data infile '/home/heikki/bugs/finstaffgrouppractice' into table fin_staffgroup_practice;
Query OK, 246 rows affected (0.01 sec)
Records: 246  Deleted: 0  Skipped: 0  Warnings: 0

mysql> load data infile '/home/heikki/bugs/finstaffgroup' into table fin_staff_group;
ERROR 13 (HY000): Can't get stat of '/home/heikki/bugs/finstaffgroup' (Errcode: 2)
mysql> load data infile '/home/heikki/bugs/finpstaffgroup' into table fin_staff_group;
Query OK, 265 rows affected (0.00 sec)
Records: 265  Deleted: 0  Skipped: 0  Warnings: 0

mysql> show table status;
+-------------------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-------------------+----------+----------------+----------------------------------------------------------------------------------+
| Name                    | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time         | Update_time | Check_time | Collation         | Checksum | Create_options | Comment                                                                          |
+-------------------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-------------------+----------+----------------+----------------------------------------------------------------------------------+
| fin_billing_rate        | InnoDB |      10 | Compact    |    3 |           5461 |       16384 |               0 |        49152 |         0 |          68705 | 2006-07-27 22:35:02 | NULL        | NULL       | latin1_swedish_ci |     NULL | NULL           | InnoDB free: 0 kB                                                                |
| fin_practice            | InnoDB |      10 | Compact    |  115 |            427 |       49152 |               0 |            0 |         0 |           NULL | 2006-07-27 22:35:51 | NULL        | NULL       | latin1_swedish_ci |     NULL | NULL           | InnoDB free: 0 kB                                                                |
| fin_staff_group         | InnoDB |      10 | Compact    |  239 |            205 |       49152 |               0 |            0 |         0 |           NULL | 2006-07-27 22:32:52 | NULL        | NULL       | latin1_swedish_ci |     NULL | NULL           | InnoDB free: 0 kB                                                                |
| fin_staffgroup_practice | InnoDB |      10 | Compact    |  246 |             66 |       16384 |               0 |        32768 |         0 |           NULL | 2006-07-27 22:36:17 | NULL        | NULL       | latin1_swedish_ci |     NULL | NULL           | InnoDB free: 0 kB; (`practice_name`) REFER `ts/fin_practice`(`practice_name`); ( |
| mw_log_activity         | InnoDB |      10 | Compact    |  103 |            159 |       16384 |               0 |        32768 |         0 |            122 | 2006-07-27 22:35:17 | NULL        | NULL       | latin1_swedish_ci |     NULL | NULL           | InnoDB free: 0 kB; (`activity_code`) REFER `ts/mw_log_activity_desc`(`activity_c |
| mw_log_activity_desc    | InnoDB |      10 | Compact    |    6 |           2730 |       16384 |               0 |            0 |         0 |           NULL | 2006-07-27 22:35:17 | NULL        | NULL       | latin1_swedish_ci |     NULL | NULL           | InnoDB free: 0 kB                                                                |
+-------------------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-------------------+----------+----------------+----------------------------------------------------------------------------------+
6 rows in set (0.00 sec)

mysql> set foreign_key_checks=1;
Query OK, 0 rows affected (0.00 sec)

mysql> update fin_billing_rate set effective_thru_period = 200511 where emp_nbr =
    -> '00779801' and effective_from_period = 200512
    -> ;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 3  Changed: 0  Warnings: 0

try running this proc:

DELIMITER $$;

DROP PROCEDURE IF EXISTS `fin`.`updatefinbillingratetest`$$

CREATE PROCEDURE `fin`.`updatefinbillingratetest` ()
BEGIN
DECLARE done INT DEFAULT 0;
declare empnbr varchar(8);
declare fromperiod numeric(6);
declare thruperiod numeric(6);
declare cur1 cursor for select emp_nbr,effective_from_period,effective_thru_period from fin_billing_rate;
DECLARE CONTINUE HANDLER FOR SQLSTATE '02000' SET done = 1;
open cur1;
repeat fetch cur1 into empnbr,fromperiod,thruperiod;
update fin_billing_rate set effective_thru_period = thruperiod + 1 where emp_nbr = empnbr and effective_from_period = fromperiod;
update fin_billing_rate set effective_thru_period = thruperiod where emp_nbr = empnbr and effective_from_period = fromperiod;
until done end repeat;
close cur1;
END$$

DELIMITER ;$$

Steve,

I still cannot repeat the crash.

Note that the triggers can cause the data to be different depending on in which order it is imported into MySQL. That is why I would need a complete SQL file so that I know that I am doing the test in the exact same order as you did.

Anyway, I believe there is a bug in the multi-range search in MySQL. It has not been extensively tested.

Regards,

Heikki

mysql> CREATE PROCEDURE `updatefinbillingratetest` ()
    -> BEGIN
    -> DECLARE done INT DEFAULT 0;
    -> declare empnbr varchar(8);
    -> declare fromperiod numeric(6);
    -> declare thruperiod numeric(6);
    -> declare cur1 cursor for select
    -> emp_nbr,effective_from_period,effective_thru_period from fin_billing_rate;
    -> DECLARE CONTINUE HANDLER FOR SQLSTATE '02000' SET done = 1;
    -> open cur1;
    -> repeat fetch cur1 into empnbr,fromperiod,thruperiod;
    -> update fin_billing_rate set effective_thru_period = thruperiod + 1 where emp_nbr
    -> = empnbr and effective_from_period = fromperiod;
    -> update fin_billing_rate set effective_thru_period = thruperiod where emp_nbr =
    -> empnbr and effective_from_period = fromperiod;
    -> until done end repeat;
    -> close cur1;
    -> END$$

DELIMITER ;Query OK, 0 rows affected (0.01 sec)

mysql>
mysql> DELIMITER ;
mysql> call updatefinbillingratetest();
Query OK, 3 rows affected (18.50 sec)

mysql> call updatefinbillingratetest();
Query OK, 3 rows affected (0.01 sec)

mysql> call updatefinbillingratetest();
Query OK, 3 rows affected (0.02 sec)

mysql> call updatefinbillingratetest();
Query OK, 3 rows affected (0.01 sec)

Hi Heikki,

I have uploaded a file that crashes for me whilst being piped, which contains all of the tables referenced in this bug, as well as the procedure, and the procedure call, to our ftp site:

ftp://ftp.mysql.com/pub/mysql/download/bug19834.tar.gz

[root@net-sup1 mysql-5.0.22]# mysql -u root -S /data0/mysql/mysql5-3311.sock test < bug19834.sql 
ERROR 2013 (HY000) at line 616: Lost connection to MySQL server during query

If this doesn't crash for you straight away (or at least, once it reaches the end of the script), then let me know and I will upload the my.cnf used also.

Best regards

Mark

I am able to repeat now with 5.0.22.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1168821168 (LWP 4942)]
lock_sec_rec_cons_read_sees (rec=0x0, index=0x4033d668, view=0x22)
    at ut0byte.ic:95
95      ut0byte.ic: No such file or directory.
        in ut0byte.ic
Current language:  auto; currently c
(gdb) bt
#0  lock_sec_rec_cons_read_sees (rec=0x0, index=0x4033d668, view=0x22)
    at ut0byte.ic:95
#1  0x082b95b1 in row_search_for_mysql (buf=0x899bea8 "\005'", mode=2,
    prebuilt=0x8b4e0e8, match_mode=1, direction=1) at row0sel.c:3800
#2  0x0821e3c3 in ha_innobase::general_fetch (this=0x8caf180,
    buf=0x22 <Address 0x22 out of bounds>, direction=34, match_mode=34)
    at ha_innodb.cc:3980
#3  0x08213c8a in handler::read_range_next (this=0x8caf180) at handler.cc:2572
#4  0x08213ab5 in handler::read_multi_range_next (this=0x8caf180,
    found_range_p=0x22) at handler.cc:2456
#5  0x08206d13 in QUICK_RANGE_SELECT::get_next (this=0x8b55620)
    at opt_range.cc:6331
#6  0x08206858 in QUICK_ROR_INTERSECT_SELECT::get_next (this=0x899c500)
    at opt_range.cc:6133
#7  0x0820db8d in rr_quick (info=0x45aab020) at records.cc:224
#8  0x081d43dd in mysql_update (thd=0x8996a70, table_list=0x8dd2c10,
    fields=@0x8dd5ef0, values=@0x8dd60c4, conds=0x8caee48, order_num=34,
    order=0x0, limit=4294967292, handle_duplicates=DUP_ERROR, ignore=false)
    at sql_update.cc:436
#9  0x08179f6a in mysql_execute_command (thd=0x8996a70) at sql_parse.cc:3211
#10 0x08270581 in sp_instr_stmt::exec_core (this=0x900, thd=0x22, nextp=0x900)
    at sp_head.cc:2304
#11 0x0827029f in sp_lex_keeper::reset_lex_and_exec_core (this=0x8dd3464,
    thd=0x8996a70, nextp=0x22, open_tables=false, instr=0x8dd3440)
    at sp_head.cc:2183
#12 0x08270463 in sp_instr_stmt::execute (this=0x8dd3440, thd=0x8996a70,
    nextp=0x45aaba94) at sp_head.cc:2257
#13 0x0826da91 in sp_head::execute (this=0x8dd1c30, thd=0x8996a70)
    at sp_head.cc:1059
#14 0x0826e8d5 in sp_head::execute_procedure (this=0x8dd1c30, thd=0x8996a70,
    args=0x8996f38) at sp_head.cc:1499
#15 0x0817ee00 in mysql_execute_command (thd=0x8996a70) at sql_parse.cc:4423
#16 0x08181d40 in mysql_parse (thd=0x8996a70,
    inBuf=0x89ab0d8 "CALL updatefinbillingratetest()", length=144272044)
    at sql_parse.cc:5695
#17 0x08177a09 in dispatch_command (command=144271984, thd=0x8996a70,
    packet=0x8a390a1 "CALL updatefinbillingratetest()",
    packet_length=144355544) at sql_parse.cc:1736
#18 0x0817753d in do_command (thd=0x8996a70) at sql_parse.cc:1522
#19 0x081768b2 in handle_one_connection (arg=0x8981f08) at sql_parse.cc:1165
#20 0x40041b63 in start_thread () from /lib/tls/libpthread.so.0
#21 0x4024b18a in clone () from /lib/tls/libc.so.6
(gdb) frame 1
#1  0x082b95b1 in row_search_for_mysql (buf=0x899bea8 "\005'", mode=2,
    prebuilt=0x8b4e0e8, match_mode=1, direction=1) at row0sel.c:3800
3800                    } else if (!lock_sec_rec_cons_read_sees(rec, index,
(gdb) list
3795                                            goto next_rec;
3796                                    }
3797
3798                                    rec = old_vers;
3799                            }
3800                    } else if (!lock_sec_rec_cons_read_sees(rec, index,
3801                                                            trx->read_view)) {
3802                            /* We are looking into a non-clustered index,
3803                            and to get the right version of the record we
3804                            have to look also into the clustered index: this

Hi!

I found a bug. The problem is with the isolation level READ COMMITTED and an open consistent read cursor where the user performs other SQL statements interleaved with fetches from the cursor. InnoDB closes the transaction 'read view' at the end or the start of each SQL statement. This leaves the cursor with no read view! The seg fault resulted from trx->read_view being NULL.

open cur1;
repeat fetch cur1 into empnbr,fromperiod,thruperiod;
update fin_billing_rate set effective_thru_period = thruperiod + 1 where emp_nbr = empnbr and effective_from_period = fromperiod;
update fin_billing_rate set effective_thru_period = thruperiod where emp_nbr = empnbr and effective_from_period = fromperiod;
until done end repeat;
close cur1;

Fix: Remove the code below from ha_innobase::start_stmt()

        if (trx->isolation_level <= TRX_ISO_READ_COMMITTED
                                                && trx->global_read_view) {
                /* At low transaction isolation levels we let
                each consistent read set its own snapshot */

                read_view_close_for_mysql(trx);
        }

Assigning this to Marko.

Thank you,

Heikki

Thanks guys!

Mark

Merged into 5.1.12

Noted in 5.0.25, 5.1.12 changelogs.

Using cursors with READ COMMITTED isolation level could cause InnoDB
to crash.

Hi! no need for 200M testcase. The attached 2kb testcase will cause the same crash!! Maybe put into testsuite?

Attachment: bug19834_reduced.sql (text/x-delimtext), 2.39 KiB.

bug #23075 marked as duplicate is this

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)

Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug. Re-closing.

Pushed into mysql-next-mr (revid:alik@sun.com-20100524190136-egaq7e8zgkwb9aqi) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (pib:16)

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)

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)

Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.

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)

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)

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)