Assertion `0' failed in net_end_statement(THD*) on concurrent SELECT FROM I_S.INNODB_SYS_INDEXES and ALTER TABLE
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MariaDB |
Fix Released
|
Medium
|
Sergei Golubchik | ||
Percona Server moved to https://jira.percona.com/projects/PS |
Incomplete
|
Medium
|
Unassigned | ||
5.1 |
Won't Fix
|
Medium
|
Unassigned | ||
5.5 |
Incomplete
|
Medium
|
Unassigned |
Bug Description
Version: '5.3.4-
mysqld: protocol.cc:509: void net_end_
#8 0xb741d014 in __assert_fail () from /lib/libc.so.6
#9 0x082c4fad in net_end_statement (thd=0x9eebc88) at protocol.cc:509
#10 0x082e2484 in dispatch_command (command=COM_QUERY, thd=0x9eebc88,
packet=
at sql_parse.cc:1620
#11 0x082e08df in do_command (thd=0x9eebc88) at sql_parse.cc:923
#12 0x082dd865 in handle_
#13 0xb76abb25 in start_thread () from /lib/libpthread
Query (0x9f2e398): SELECT * FROM INFORMATION_
Connection ID (thread ID): 4
Status: NOT_KILLED
bzr version-info
revision-id: <email address hidden>
date: 2012-02-16 20:15:57 +0400
build-date: 2012-02-17 07:40:46 +0400
revno: 3424
Also reproducible on MariaDB 5.1 and 5.2.
Could not reproduce on 5.5, but the test is not deterministic., so there is no guarantee. It is, however, noticeable, that the flow works much slower on 5.5
# MTR test case (please note that the number of attempts is set in the $run variable):
--source include/
CREATE TABLE t1 (
a DATE,
b TIME,
c VARCHAR(1),
d INT
) ENGINE=InnoDB;
--connect (con1,127.
--connect (con2,127.
let $run=1000;
--disable_query_log
--disable_
while ($run)
{
--echo # $run attempts left
--connection con1
--send
ALTER TABLE t1 ADD KEY(d);
--connection con2
SELECT * FROM INFORMATION_
--connection con1
--reap
ALTER TABLE t1 DROP KEY d;
--dec $run
}
# End of test case
Related branches
tags: | added: xtradb |
tags: | added: assertion |
affects: | percona-xtradb → percona-server |
Changed in maria: | |
status: | Fix Committed → Fix Released |
it's xtradb bug. eventually in the test case it tries to put some garbage into a row of the I_S.INNODB_ SYS_INDEXES table, that fails, and the error is propagated all the way up. The assertion in the server fires because the error is not sent to the user. I'll fix that - the server will send a generic error if an I_S plugin failed without reporting an error. But the real bug is trying to put garbage into INNODB_SYS_INDEXES. This should've not happened in the first place.