| Bug #68051 | Killing a query inside InnoDB causes it to eventually crash with an assertion | ||
|---|---|---|---|
| Submitted: | 8 Jan 2013 19:22 | Modified: | 11 Mar 2013 19:21 |
| Reporter: | Davi Arnaut (OCA) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: InnoDB storage engine | Severity: | S1 (Critical) |
| Version: | 5.5.29 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | assertion failure, btr0pcur.c, crash, KILL QUERY, regression | ||
[8 Jan 2013 19:22]
Davi Arnaut
[8 Jan 2013 20:10]
Davi Arnaut
Also worth mentioning that the test for Bug#14704286 does not actually test the change, it is just killing a query at some random point of its execution.
[9 Jan 2013 6:15]
MySQL Verification Team
Version: '5.5.29-debug' MySQL Community Server - Debug (GPL) [ERROR] mysql_ha_read: Got error -1 when reading table 't1' [ERROR] mysql_ha_read: Got error -1 when reading table 't1' len 120; hex 1085530463c0df04c0f2550400000000000 <cut> InnoDB: Assertion failure in thread 5024 in file btr0pcur.c line 250 InnoDB: We intentionally generate a memory trap. mysqld-debug.exe!btr_pcur_restore_position_func()[btr0pcur.c:250] mysqld-debug.exe!sel_restore_position_for_mysql()[row0sel.c:3100] mysqld-debug.exe!row_search_for_mysql()[row0sel.c:3848] mysqld-debug.exe!ha_innobase::general_fetch()[ha_innodb.cc:6195] mysqld-debug.exe!ha_innobase::rnd_next()[ha_innodb.cc:6389] mysqld-debug.exe!mysql_ha_read()[sql_handler.cc:660] mysqld-debug.exe!mysql_execute_command()[sql_parse.cc:3737] mysqld-debug.exe!mysql_parse()[sql_parse.cc:5627] mysqld-debug.exe!dispatch_command()[sql_parse.cc:1037] mysqld-debug.exe!do_command()[sql_parse.cc:773] mysqld-debug.exe!do_handle_one_connection()[sql_connect.cc:853] mysqld-debug.exe!handle_one_connection()[sql_connect.cc:772] mysqld-debug.exe!pthread_start()[my_winthread.c:61] mysqld-debug.exe!_callthreadstartex()[threadex.c:348] mysqld-debug.exe!_threadstartex()[threadex.c:331]
[16 Feb 2013 1:13]
Jervin R
Davi,
I tested your test case on 5.5.29 without much luck, even manually - is there something I might be missing? The running sandbox has debug-sync-timeout=5.
[revin@forge mysql-test]$ ./mtr --vardir=/ssd/msb/var --extern socket=/tmp/mysql_sandbox5529.sock t/68051.test
Logging: ./mtr --vardir=/ssd/msb/var --extern socket=/tmp/mysql_sandbox5529.sock t/68051.test
MySQL Version 5.5.29
Checking supported features...
- skipping ndbcluster
- skipping SSL, mysqld not compiled with SSL
Collecting tests...
vardir: /ssd/msb/var
Using server port 45511
==============================================================================
TEST RESULT TIME (ms) or COMMENT
--------------------------------------------------------------------------
worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 13000..13009
CREATE TABLE t1 (a INT PRIMARY KEY) ENGINE=InnoDB;
INSERT INTO t1 VALUES (1),(2),(3),(4),(5),(6);
HANDLER t1 OPEN;
HANDLER t1 READ FIRST;
a
1
SET DEBUG_SYNC = 'row_search_rec_loop SIGNAL parked WAIT_FOR go';
HANDLER t1 READ NEXT;
SELECT @@version;
@@version
5.5.29-debug
SET DEBUG_SYNC = 'now WAIT_FOR parked';
Warnings:
Warning 1639 debug sync point wait timed out
SELECT ID INTO @conn_id FROM INFORMATION_SCHEMA.PROCESSLIST
WHERE STATE = 'debug sync point: row_search_rec_loop';
Warnings:
Warning 1329 No data - zero rows fetched, selected, or processed
main.68051 [ fail ]
Test ended at 2013-02-15 20:03:05
mysqltest: At line 13: query 'KILL QUERY @conn_id' failed: 1094: Unknown thread id: 0
mysqltest failed but provided no output
- saving '/ssd/msb/var/log/main.68051/' to '/ssd/msb/var/log/main.68051/'
--------------------------------------------------------------------------
The servers were restarted 0 times
Spent 0.000 of 6 seconds executing testcases
Completed: Failed 1/1 tests, 0.00% were successful.
Failing test(s): main.68051
The log files in var/log may give you some hint of what went wrong.
If you want to report this error, please read first the documentation
at http://dev.mysql.com/doc/mysql/en/mysql-test-suite.html
mysql-test-run: *** ERROR: there were failing test cases
[11 Mar 2013 19:21]
Bugs System
Added 5.1.69, 5.5.31, 5.6.11, 5.7.1 changelog. Killing a query caused an InnoDB assertion failure when the same table (cursor) instance was used again. This is the result of a regression error introduced by the fix for Bug#14704286. The fix introduced a check to handle kill signals for long running queries but the cursor was not restored to the proper state.
[11 Apr 2013 9:39]
MySQL Verification Team
bug #68928 is a duplicate
[7 Jun 2013 17:42]
MySQL Verification Team
Bug #69426 is a duplicate
[24 Dec 2014 7:23]
MySQL Verification Team
Bug #75304 marked as duplicate of this
[25 Apr 2015 10:13]
MySQL Verification Team
http://bugs.mysql.com/bug.php?id=76584 is a duplicate of this
[28 Apr 2015 12:10]
MySQL Verification Team
http://bugs.mysql.com/bug.php?id=69312 is a duplicate of this
