Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 10.0.8
-
Fix Version/s: 10.0.9
-
Component/s: None
-
Labels:None
Description
The test case is not great, it uses a sleep, but more civilized ways (like count_sessions and such) didn't do the trick reliably – the problem happens anyway, but the server goes down before the assertion failure fully blossoms. The idea of the rough test is to show that the failure actually happens on normal session disconnect, rather than on server shutdown or KILL.
--connect(con1,localhost,root,,) SET optimizer_switch = 'materialization=on,semijoin=on'; CREATE TABLE t1 (f1 VARCHAR(3)); CREATE TABLE t2 (f2 VARCHAR(3), INDEX(f2)); INSERT INTO t1 VALUES ('foo'),('bar'); INSERT INTO t2 VALUES ('baz'),('qux'); SELECT * FROM t1 WHERE ( 'abc', 'xyz' ) IN ( SELECT f1, f1 FROM t1 WHERE f1 IN ( SELECT MAX( f2) FROM t2 ) ); --disconnect con1 --sleep 2 --connection default DROP TABLE t1, t2;
10.0/sql/sql_class.cc:1636: virtual THD::~THD(): Assertion `status_var.memory_used == 0' failed. 140225 12:45:33 [ERROR] mysqld got signal 6 ;
#6 0x00007f4fca099621 in *__GI___assert_fail (assertion=0xee0df7 "status_var.memory_used == 0", file=<optimized out>, line=1636, function=0xee3430 "virtual THD::~THD()") at assert.c:81 #7 0x0000000000636516 in THD::~THD (this=0x7f4fc2484070, __in_chrg=<optimized out>) at 10.0/sql/sql_class.cc:1636 #8 0x000000000063669e in THD::~THD (this=0x7f4fc2484070, __in_chrg=<optimized out>) at 10.0/sql/sql_class.cc:1641 #9 0x00000000005b7c2f in unlink_thd (thd=0x7f4fc2484070) at 10.0/sql/mysqld.cc:2722 #10 0x00000000005b7f8f in one_thread_per_connection_end (thd=0x7f4fc2484070, put_in_cache=true) at 10.0/sql/mysqld.cc:2833 #11 0x0000000000787867 in do_handle_one_connection (thd_arg=0x7f4fc2484070) at 10.0/sql/sql_connect.cc:1390 #12 0x0000000000787514 in handle_one_connection (arg=0x7f4fc2484070) at 10.0/sql/sql_connect.cc:1293 #13 0x0000000000a2a921 in pfs_spawn_thread (arg=0x7f4fc367cd50) at 10.0/storage/perfschema/pfs.cc:1853 #14 0x00007f4fcbc3db50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #15 0x00007f4fca148a7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #16 0x0000000000000000 in ?? ()
Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x0): Connection ID (thread ID): 4 Status: KILL_CONNECTION
Stack trace from:
revision-id: monty@askmonty.org-20140222011156-i1pa6zm2iltb4usv revno: 4007 branch-nick: 10.0 Build with: 'cmake . -DCMAKE_BUILD_TYPE=Debug && make'
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
The bug was gone along with the following merge:
revno: 4015 [merge] revision-id: sergii@pisem.net-20140228090031-f1iw9irc6a8m7fbv parent: bar@mnogosearch.org-20140227154400-3rs1m2c47lqum7js parent: sergii@pisem.net-20140227214342-gpyum52oiuxm4tgs committer: Sergei Golubchik <sergii@pisem.net> branch nick: 10.0 timestamp: Fri 2014-02-28 10:00:31 +0100 message: merge
or, more precisely, with the following nested merge:
revno: 4007.1.1 [merge]
revision-id: sergii@pisem.net-20140226142807-snbx56wm1am1t90o
parent: monty@askmonty.org-20140222011156-i1pa6zm2iltb4usv
parent: sergii@pisem.net-20140225150435-rpxxfpnsij95boxo
committer: Sergei Golubchik <sergii@pisem.net>
branch nick: 10.0
timestamp: Wed 2014-02-26 15:28:07 +0100
message:
10.0-base merge
------------------------------------------------------------
revno: 3427.43.5 [merge]
revision-id: sergii@pisem.net-20140225150435-rpxxfpnsij95boxo
parent: psergey@askmonty.org-20140225090157-keyn5zcp8c94u20w
parent: sergii@pisem.net-20140222215120-1thda2f7s8luzgaq
committer: Sergei Golubchik <sergii@pisem.net>
branch nick: 10.0-base
timestamp: Tue 2014-02-25 16:04:35 +0100
message:
5.5 merge
Unfortunately, digging deeper is impossible because the assertion does not exist on 5.5, so it was not reproducible on 5.5 code base either before or after the fix.
Doesn't fail on revno 4017, need to find out why, or at least when it stopped failing.