Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 10.0.14, 10.1.1
-
Component/s: Data Manipulation - Update
-
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
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
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.
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.
Vicentiu Ciorbaru, 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.