[MDEV-7038] Assertion `status_var.memory_used == 0' failed in THD::~THD() on disconnect after executing EXPLAIN for multi-table UPDATE Created: 2014-11-06  Updated: 2015-05-03  Resolved: 2015-05-03

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Update
Affects Version/s: 10.0.14, 10.1.1
Fix Version/s: 10.0.17, 10.1.4

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Oleksandr Byelkin
Resolution: Fixed Votes: 0
Labels: None


 Description    

CREATE TABLE t1 (a INT);
 
CREATE VIEW v1 AS SELECT * FROM t1;
 
INSERT INTO t1 VALUES (1),(2);
 
EXPLAIN UPDATE v1, mysql.user SET v1.a = v1.a + 1;
 
# If you are running it via the client (as opposed to MTR),
 
# disconnect now
 

10.0/sql/sql_class.cc:1632: virtual THD::~THD(): Assertion `status_var.memory_used == 0' failed.
 
141107  1:43:20 [ERROR] mysqld got signal 6 ;
 

#6  0x00007fe03921b6f1 in *__GI___assert_fail (assertion=0xf0fccf "status_var.memory_used == 0", file=<optimized out>, line=1632, function=0xf124b0 "virtual THD::~THD()") at assert.c:81
 
#7  0x000000000063f5e8 in THD::~THD (this=0x7fe033f2f070, __in_chrg=<optimized out>) at 10.0/sql/sql_class.cc:1632
 
#8  0x000000000063f770 in THD::~THD (this=0x7fe033f2f070, __in_chrg=<optimized out>) at 10.0/sql/sql_class.cc:1637
 
#9  0x00000000005bf40c in unlink_thd (thd=0x7fe033f2f070) at 10.0/sql/mysqld.cc:2770
 
#10 0x00000000005bf76c in one_thread_per_connection_end (thd=0x7fe033f2f070, put_in_cache=true) at 10.0/sql/mysqld.cc:2881
 
#11 0x0000000000794550 in do_handle_one_connection (thd_arg=0x7fe033f2f070) at 10.0/sql/sql_connect.cc:1390
 
#12 0x00000000007941fd in handle_one_connection (arg=0x7fe033f2f070) at 10.0/sql/sql_connect.cc:1293
 
#13 0x0000000000ccb4a6 in pfs_spawn_thread (arg=0x7fe033367bf0) at 10.0/storage/perfschema/pfs.cc:1860
 
#14 0x00007fe03add4b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
 
#15 0x00007fe0392cc20d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Stack trace from

 
revision-id: sergii@pisem.net-20141103164737-457hfby1eg82zol9
 
date: 2014-11-03 17:47:37 +0100
 
build-date: 2014-11-07 01:51:22 +0400
 
revno: 4471
 
branch-nick: 10.0



 Comments   
Comment by Sergei Petrunia [ 2015-02-17 ]

cvicentiu, can you get a stack trace of where we have allocated the memory that was lost? This would give a clue about which part of the code was lost.

Comment by Vicențiu Ciorbaru [ 2015-05-02 ]

Hi Elena,
This bug is no longer reproducible on the current version of 10.0. As discussed with Sergei Petrunia, I've added the test case for it in the tree, within t/explain_non_select.test

The patch that fixes this is somewhere between 10.0.16 and 10.0.17, but I didn't spend too much time trying to figure out which commit.
Let me know if you are ok with it like this.

Comment by Elena Stepanova [ 2015-05-03 ]

The problem disappeared from 10.0 tree starting from this commit:

commit d7e7862364ae344fea5657eb5aae9db3fbb84553 a06624d61f36c70edd63adcfe2803bb7a8564de5 fdd6c111c254c5044cd9b6c2f7e4d0c74f427a79
 
Merge: a06624d fdd6c11
 
Author: Sergei Golubchik <serg@mariadb.org>
 
Date:   Wed Feb 18 15:16:27 2015 +0100
 
 
 
    Merge branch '5.5' into 10.0

particularly, with this change

diff --git a/sql/sql_derived.cc b/sql/sql_derived.cc
 
index 4fbf428..c68e7f4 100644
 
--- a/sql/sql_derived.cc
 
+++ b/sql/sql_derived.cc
 
@@ -516,6 +516,9 @@ bool mysql_derived_merge_for_insert(THD *thd, LEX *lex, TABLE_LIST *derived)
 
     DBUG_RETURN(FALSE);
 
   if (derived->is_materialized_derived())
 
     DBUG_RETURN(mysql_derived_prepare(thd, lex, derived));
 
+  if ((thd->lex->sql_command == SQLCOM_UPDATE_MULTI ||
 
+       thd->lex->sql_command == SQLCOM_DELETE_MULTI))
 
+    DBUG_RETURN(FALSE);
 
   if (!derived->is_multitable())
 
   {
 
     if (!derived->single_table_updatable())

which belongs to this bugfix for 5.5.42/10.0.17:

revno: 4429
 
revision-id: sanja@askmonty.org-20150211002650-802oojju9kcg7s10
 
parent: holyfoot@askmonty.org-20150210121631-byrqdvs0ctrrnsf6
 
committer: sanja@askmonty.org
 
branch nick: work-maria-5.5-MDEV-7260
 
timestamp: Wed 2015-02-11 01:26:50 +0100
 
message:
 
  MDEV-7260: Crash in get_best_combination when executing multi-table UPDATE with nested views
 
  
  Do not use merge_for_insert for commands which use SELECT because optimizer can't work with such tables.
 
  
  Fixes which makes multi-delete working with normally merged views.

Generated at Thu Feb 08 07:16:29 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.