Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.0.14, 10.1.1
-
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
|
Attachments
Activity
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.
|
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.