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

[15 May 2006 23:29] Steve DeWitt
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
[15 May 2006 23:36] Steve DeWitt
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
[16 May 2006 5:23] Valeriy Kravchuk
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.
[16 May 2006 15:30] Steve DeWitt
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
[16 May 2006 18:14] Steve DeWitt
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
[16 May 2006 18:59] Valeriy Kravchuk
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.
[16 May 2006 19:10] Steve DeWitt
this is the data

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

[16 May 2006 19:20] Steve DeWitt
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.
[17 May 2006 19:23] Miguel Solorzano
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)
[17 May 2006 19:53] Steve DeWitt
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.
[26 May 2006 21:05] Valeriy Kravchuk
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.
[31 May 2006 16:31] Steve DeWitt
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?
[18 Jul 2006 17:40] Mark Leith
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 (?)
[18 Jul 2006 20:14] Mark Leith
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..
[18 Jul 2006 20:24] Mark Leith
Updated bug details
[27 Jul 2006 16:47] Heikki Tuuri
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
[27 Jul 2006 17:29] Steve DeWitt
Great, I will let you guys hammer this out. I have supplied MySQL with plenty of sql, ddl, data to reproduce this issue.
thanks
[27 Jul 2006 19:39] Heikki Tuuri
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
[27 Jul 2006 19:56] Steve DeWitt
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 ;$$
[27 Jul 2006 20:24] Heikki Tuuri
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)
[27 Jul 2006 20:50] Mark Leith
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
[28 Jul 2006 8:02] Heikki Tuuri
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
[28 Jul 2006 9:03] Heikki Tuuri
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
[28 Jul 2006 13:50] Mark Leith
Thanks guys!

Mark
[13 Sep 2006 8:07] Timothy Smith
Merged into 5.1.12
[13 Sep 2006 17:10] Paul Dubois
Noted in 5.0.25, 5.1.12 changelogs.

Using cursors with READ COMMITTED isolation level could cause InnoDB
to crash.
[27 Sep 2006 6:11] Shane Bester
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.

[8 Oct 2006 13:46] Shane Bester
bug #23075 marked as duplicate is this
[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 2:09] 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:48] Paul Dubois
Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.
[17 Jun 2010 12:19] 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)