[MDEV-31314] Assertion `status_var.local_memory_used == 0 || !debug_assert_on_not_freed_memory' failed upon user variable in virtual column or default Created: 2023-05-19  Updated: 2023-11-28

Status: Open
Project: MariaDB Server
Component/s: Variables, Virtual Columns
Affects Version/s: 10.3, 10.4, 10.5, 10.6, 10.8, 10.9, 10.10, 10.11, 11.0
Fix Version/s: 10.4, 10.5, 10.6, 10.11, 11.0

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


 Description   

CREATE TABLE t (f INT);
INSERT INTO t VALUES (1),(2);
ALTER TABLE t ADD vcol INT GENERATED ALWAYS AS (@var := f), ALGORITHM=COPY;
 
--connect (con1,localhost,root,,)
 
SET @var = '8+ symbols';
SELECT COUNT(*) FROM t;
 
--connection default
SELECT * FROM t;
 
# Cleanup
DROP TABLE t;
--disconnect con1

10.4 956d6c4a

Warning:   16 bytes freed by T@3, allocated by T@5 at mysys/my_malloc.c:155, sql/item_func.cc:4813, sql/item_func.cc:4858, sql/item_func.cc:5114, sql/set_var.cc:902, sql/set_var.cc:740, sql/sql_parse.cc:5045, sql/sql_parse.cc:8008
2023-05-19 22:11:40 0 [Note] /mnt8t/bld/10.4-debug/bin/mysqld (initiated by: unknown): Normal shutdown
mysqld: /data/src/10.4/sql/mysqld.cc:3801: void my_malloc_size_cb_func(long long int, my_bool): Assertion `(longlong) thd->status_var.local_memory_used >= 0 || !debug_assert_on_not_freed_memory' failed.
mysqld: /data/src/10.4/sql/sql_class.cc:1723: virtual THD::~THD(): Assertion `status_var.local_memory_used == 0 || !debug_assert_on_not_freed_memory' failed.
230519 22:11:40 [ERROR] mysqld got signal 6 ;
 
#5  0x00007f90a6f74df2 in __GI___assert_fail (assertion=0x556e086014a0 "status_var.local_memory_used == 0 || !debug_assert_on_not_freed_memory", file=0x556e08600f38 "/data/src/10.4/sql/sql_class.cc", line=1723, function=0x556e08601446 "virtual THD::~THD()") at ./assert/assert.c:101
#6  0x0000556e07706ac9 in THD::~THD (this=0x7f9084000da0, __in_chrg=<optimized out>) at /data/src/10.4/sql/sql_class.cc:1723
#7  0x0000556e07706d08 in THD::~THD (this=0x7f9084000da0, __in_chrg=<optimized out>) at /data/src/10.4/sql/sql_class.cc:1729
#8  0x0000556e07631e0c in one_thread_per_connection_end (thd=0x7f9084000da0, put_in_cache=true) at /data/src/10.4/sql/mysqld.cc:2785
#9  0x0000556e0791c19f in do_handle_one_connection (connect=0x556e0ac1bfa0) at /data/src/10.4/sql/sql_connect.cc:1431
#10 0x0000556e0791be88 in handle_one_connection (arg=0x556e0ac1bfa0) at /data/src/10.4/sql/sql_connect.cc:1324
#11 0x0000556e07e6de48 in pfs_spawn_thread (arg=0x556e0ab643b0) at /data/src/10.4/storage/perfschema/pfs.cc:1869
#12 0x00007f90a6fc8fd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#13 0x00007f90a70495bc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Reproducible with at least MyISAM, Aria, InnoDB (ALGORITHM=COPY is there for InnoDB), on all existing versions, including earlier minor releases.



 Comments   
Comment by Elena Stepanova [ 2023-06-19 ]

Different way to get what appears to be the same problem (without ALTER and intermediate variable assignment, but instead SELECT from I_S is needed on some reason).

--source include/have_innodb.inc
 
CREATE TABLE t (a INT, b VARCHAR(8) GENERATED ALWAYS AS (@A := '08:49:25'));
INSERT INTO t (a) VALUES (1);
--disable_result_log
SELECT * FROM INFORMATION_SCHEMA.STATISTICS;
--enable_result_log
 
--connect (con1,localhost,root,,)
SELECT b FROM t;
 
# Cleanup
DROP TABLE t;
--disconnect con1

Generated at Thu Feb 08 10:22:54 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.