[MDEV-22805] SIGSEGV in check_fields on UPDATE (optimized builds) | Assertion `thd->lex->sql_command == SQLCOM_UPDATE' failed. Created: 2020-06-05  Updated: 2020-10-30  Resolved: 2020-10-27

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Update
Affects Version/s: 10.4, 10.5
Fix Version/s: 10.4.16, 10.5.7

Type: Bug Priority: Critical
Reporter: Roel Van de Paar Assignee: Dmitry Shulga
Resolution: Fixed Votes: 0
Labels: not-10.1, not-10.2, not-10.3, regression


 Description    

USE test;
 
CREATE TABLE t(id INT);
 
UPDATE t FOR PORTION OF APPTIME FROM (SELECT s FROM t LIMIT 1) TO h() SET t.id=t.id + 5;

Leads to:

10.5.4 701efbb25b738f0c971798c5234d4d66b9235e47

 
Core was generated by `/test/MD030620-mariadb-10.5.4-linux-x86_64-opt/bin/mysqld --no-defaults --core-'.
 
Program terminated with signal SIGSEGV, Segmentation fault.
 
#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=11)
 
    at ../sysdeps/unix/sysv/linux/pthread_kill.c:57
 
[Current thread is 1 (Thread 0x1487b054e700 (LWP 2742089))]
 
(gdb) bt
 
(gdb) (gdb) #0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=11) at ../sysdeps/unix/sysv/linux/pthread_kill.c:57
 
#1  0x000055c4a62e8647 in my_write_core (sig=sig@entry=11) at /test/10.5_opt/mysys/stacktrace.c:518
 
#2  0x000055c4a5caaf4a in handle_fatal_signal (sig=11) at /test/10.5_opt/sql/signal_handler.cc:330
 
#3  <signal handler called>
 
#4  check_fields (thd=thd@entry=0x14878c012018, table=table@entry=0x14878c049f50, items=@0x14878c0167c0: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x14878c04aa38, last = 0x14878c04aa38, elements = 1}, <No data fields>}, update_view=<optimized out>) at /test/10.5_opt/sql/sql_update.cc:197
 
#5  0x000055c4a5b5e818 in Multiupdate_prelocking_strategy::handle_end (this=0x1487b054cef0, thd=0x14878c012018) at /test/10.5_opt/sql/sql_update.cc:1712
 
#6  0x000055c4a5b62a89 in mysql_multi_update_prepare (thd=thd@entry=0x14878c012018) at /test/10.5_opt/sql/sql_update.cc:1850
 
#7  0x000055c4a5ab4448 in mysql_execute_command (thd=thd@entry=0x14878c012018) at /test/10.5_opt/sql/sql_parse.cc:4439
 
#8  0x000055c4a5abbf1c in mysql_parse (thd=0x14878c012018, rawbuf=<optimized out>, length=87, parser_state=0x1487b054d4b0, is_com_multi=<optimized out>, is_next_command=<optimized out>) at /test/10.5_opt/sql/sql_parse.cc:7992
 
#9  0x000055c4a5ab1235 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x14878c012018, packet=packet@entry=0x14878c03a019 "UPDATE t FOR PORTION OF APPTIME FROM (SELECT s FROM t LIMIT 1) TO h() SET t.id=t.id + 5", packet_length=packet_length@entry=87, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /test/10.5_opt/sql/sql_parse.cc:1874
 
#10 0x000055c4a5aaf644 in do_command (thd=0x14878c012018) at /test/10.5_opt/sql/sql_parse.cc:1355
 
#11 0x000055c4a5ba47c1 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x1487ae0329b8, put_in_cache=put_in_cache@entry=true) at /test/10.5_opt/sql/sql_connect.cc:1411
 
#12 0x000055c4a5ba4b24 in handle_one_connection (arg=arg@entry=0x1487ae0329b8) at /test/10.5_opt/sql/sql_connect.cc:1313
 
#13 0x000055c4a5f1117a in pfs_spawn_thread (arg=0x1487ae04b018) at /test/10.5_opt/storage/perfschema/pfs.cc:2201
 
#14 0x00001487af9756db in start_thread (arg=0x1487b054e700) at pthread_create.c:463
 
#15 0x00001487aed7388f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Bug confirmed present in:
MariaDB: 10.4.14 (dbg), 10.4.14 (opt), 10.5.4 (dbg), 10.5.4 (opt)

Bug confirmed not present in:
MariaDB: 10.1.46 (dbg), 10.1.46 (opt), 10.2.33 (dbg), 10.2.33 (opt), 10.3.24 (dbg), 10.3.24 (opt)
MySQL: 5.5.62 (dbg), 5.5.62 (opt), 5.6.47 (dbg), 5.6.47 (opt), 5.7.29 (dbg), 5.7.29 (opt), 8.0.19 (dbg), 8.0.19 (opt)

MariaDB 10.3.24 (opt):

10.3.24 ecc7f305dde85d704a37e584c29df0ed3f97f7be

 
10.3.24>UPDATE t FOR PORTION OF APPTIME FROM (SELECT s FROM t LIMIT 1) TO h() SET t.id=t.id + 5;
 
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'FOR PORTION OF APPTIME FROM (SELECT s FROM t LIMIT 1) TO h() SET t.id=t.id + 5' at line 1



 Comments   
Comment by Roel Van de Paar [ 2020-06-15 ]

For latest 10.5 branch (4080e3acefd7e58d88c2f3539fb6a0fb359cf057):

USE test;
 
CREATE TABLE t (id INT);
 
UPDATE t FOR PORTION OF APPTIME FROM (SELECT s FROM t LIMIT 1) TO h() SET t.id=t.id+5;

Leads to:

10.5.4 4080e3acefd7e58d88c2f3539fb6a0fb359cf057 (dbg)

 
mysqld: /test/10.5_dbg/sql/sql_update.cc:192: bool check_fields(THD*, TABLE_LIST*, List<Item>&, bool): Assertion `thd->lex->sql_command == SQLCOM_UPDATE' failed.

10.5.4 4080e3acefd7e58d88c2f3539fb6a0fb359cf057 (dbg)

 
Core was generated by `/test/MD150620-mariadb-10.5.4-linux-x86_64-dbg/bin/mysqld --no-defaults --core-'.
 
Program terminated with signal SIGABRT, Aborted.
 
#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=6)
 
    at ../sysdeps/unix/sysv/linux/pthread_kill.c:57
 
[Current thread is 1 (Thread 0x1458e7957700 (LWP 2897689))]
 
(gdb) bt
 
#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ../sysdeps/unix/sysv/linux/pthread_kill.c:57
 
#1  0x000055dcae4cf4c6 in my_write_core (sig=sig@entry=6) at /test/10.5_dbg/mysys/stacktrace.c:518
 
#2  0x000055dcadc71d60 in handle_fatal_signal (sig=6) at /test/10.5_dbg/sql/signal_handler.cc:330
 
#3  <signal handler called>
 
#4  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
 
#5  0x00001458f0098801 in __GI_abort () at abort.c:79
 
#6  0x00001458f008839a in __assert_fail_base (fmt=0x1458f020f7d8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55dcae66e920 "thd->lex->sql_command == SQLCOM_UPDATE", file=file@entry=0x55dcae66e848 "/test/10.5_dbg/sql/sql_update.cc", line=line@entry=192, function=function@entry=0x55dcae66f440 <check_fields(THD*, TABLE_LIST*, List<Item>&, bool)::__PRETTY_FUNCTION__> "bool check_fields(THD*, TABLE_LIST*, List<Item>&, bool)") at assert.c:92
 
#7  0x00001458f0088412 in __GI___assert_fail (assertion=assertion@entry=0x55dcae66e920 "thd->lex->sql_command == SQLCOM_UPDATE", file=file@entry=0x55dcae66e848 "/test/10.5_dbg/sql/sql_update.cc", line=line@entry=192, function=function@entry=0x55dcae66f440 <check_fields(THD*, TABLE_LIST*, List<Item>&, bool)::__PRETTY_FUNCTION__> "bool check_fields(THD*, TABLE_LIST*, List<Item>&, bool)") at assert.c:101
 
#8  0x000055dcadab7b3a in check_fields (thd=thd@entry=0x1458ce815088, table=table@entry=0x1458ce8770c0, items=@0x1458ce8199f0: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x1458ce877ba8, last = 0x1458ce877ba8, elements = 1}, <No data fields>}, update_view=<optimized out>) at /test/10.5_dbg/sql/sql_update.cc:192
 
#9  0x000055dcadab85ba in Multiupdate_prelocking_strategy::handle_end (this=this@entry=0x1458e7955ae0, thd=thd@entry=0x1458ce815088) at /test/10.5_dbg/sql/sql_update.cc:1712
 
#10 0x000055dcadabacf1 in mysql_multi_update_prepare (thd=thd@entry=0x1458ce815088) at /test/10.5_dbg/sql/sql_update.cc:1850
 
#11 0x000055dcad9c876e in mysql_execute_command (thd=thd@entry=0x1458ce815088) at /test/10.5_dbg/sql/sql_parse.cc:4439
 
#12 0x000055dcad9d415c in mysql_parse (thd=thd@entry=0x1458ce815088, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x1458e7956350, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /test/10.5_dbg/sql/sql_parse.cc:7993
 
#13 0x000055dcad9c0c60 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x1458ce815088, packet=packet@entry=0x1458ce867089 "UPDATE t FOR PORTION OF APPTIME FROM (SELECT s FROM t LIMIT 1) TO h() SET t.id=t.id+5", packet_length=packet_length@entry=85, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /test/10.5_dbg/sql/sql_parse.cc:1874
 
#14 0x000055dcad9bf43a in do_command (thd=0x1458ce815088) at /test/10.5_dbg/sql/sql_parse.cc:1355
 
#15 0x000055dcadb1ac47 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x1458d157a808, put_in_cache=put_in_cache@entry=true) at /test/10.5_dbg/sql/sql_connect.cc:1411
 
#16 0x000055dcadb1b363 in handle_one_connection (arg=arg@entry=0x1458d157a808) at /test/10.5_dbg/sql/sql_connect.cc:1313
 
#17 0x000055dcadf7c902 in pfs_spawn_thread (arg=0x1458eec46c88) at /test/10.5_dbg/storage/perfschema/pfs.cc:2201
 
#18 0x00001458f0d7b6db in start_thread (arg=0x1458e7957700) at pthread_create.c:463
 
#19 0x00001458f017988f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

10.5.4 4080e3acefd7e58d88c2f3539fb6a0fb359cf057 (opt)

 
Core was generated by `/test/MD150620-mariadb-10.5.4-linux-x86_64-opt/bin/mysqld --no-defaults --core-'.
 
Program terminated with signal SIGSEGV, Segmentation fault.
 
#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=11)
 
    at ../sysdeps/unix/sysv/linux/pthread_kill.c:57
 
[Current thread is 1 (Thread 0x147f5211b700 (LWP 3193850))]
 
(gdb) bt
 
#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=11)
 
    at ../sysdeps/unix/sysv/linux/pthread_kill.c:57
 
#1  0x00005600de0b10b7 in my_write_core (sig=sig@entry=11) at /test/10.5_opt/mysys/stacktrace.c:518
 
#2  0x00005600dda7ae4a in handle_fatal_signal (sig=11) at /test/10.5_opt/sql/signal_handler.cc:330
 
#3  <signal handler called>
 
#4  check_fields (thd=thd@entry=0x147f2d012018, table=table@entry=0x147f2d049f50, items=..., 
    update_view=<optimized out>) at /test/10.5_opt/sql/sql_update.cc:197
 
#5  0x00005600dd92da98 in Multiupdate_prelocking_strategy::handle_end (this=0x147f52119e70, 
    thd=0x147f2d012018) at /test/10.5_opt/sql/sql_update.cc:1712
 
#6  0x00005600dd931d09 in mysql_multi_update_prepare (thd=thd@entry=0x147f2d012018)
 
    at /test/10.5_opt/sql/sql_update.cc:1850
 
#7  0x00005600dd882d78 in mysql_execute_command (thd=thd@entry=0x147f2d012018)
 
    at /test/10.5_opt/sql/sql_parse.cc:4439
 
#8  0x00005600dd88a85c in mysql_parse (thd=0x147f2d012018, rawbuf=<optimized out>, length=85, 
    parser_state=0x147f5211a430, is_com_multi=<optimized out>, is_next_command=<optimized out>)
 
    at /test/10.5_opt/sql/sql_parse.cc:7993
 
#9  0x00005600dd87fb65 in dispatch_command (command=command@entry=COM_QUERY, 
    thd=thd@entry=0x147f2d012018, 
    packet=packet@entry=0x147f2d03a019 "UPDATE t FOR PORTION OF APPTIME FROM (SELECT s FROM t LIMIT 1) TO h() SET t.id=t.id+5", packet_length=packet_length@entry=85, is_com_multi=is_com_multi@entry=false, 
    is_next_command=is_next_command@entry=false) at /test/10.5_opt/sql/sql_parse.cc:1874
 
#10 0x00005600dd87df74 in do_command (thd=0x147f2d012018) at /test/10.5_opt/sql/sql_parse.cc:1355
 
#11 0x00005600dd973b51 in do_handle_one_connection (connect=<optimized out>, 
    connect@entry=0x147f4ec33958, put_in_cache=put_in_cache@entry=true)
 
    at /test/10.5_opt/sql/sql_connect.cc:1411
 
#12 0x00005600dd973eb4 in handle_one_connection (arg=arg@entry=0x147f4ec33958)
 
    at /test/10.5_opt/sql/sql_connect.cc:1313
 
#13 0x00005600ddce2bca in pfs_spawn_thread (arg=0x147f4ec4f218)
 
    at /test/10.5_opt/storage/perfschema/pfs.cc:2201
 
#14 0x0000147f510946db in start_thread (arg=0x147f5211b700) at pthread_create.c:463
 
#15 0x0000147f5049288f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Bug confirmed present in:
MariaDB: 10.4.14 (dbg), 10.4.14 (opt), 10.5.4 (dbg), 10.5.4 (opt)

Bug confirmed not present in:
MariaDB: 10.1.46 (dbg), 10.1.46 (opt), 10.2.33 (dbg), 10.2.33 (opt), 10.3.24 (dbg), 10.3.24 (opt)
MySQL: 5.5.62 (dbg), 5.5.62 (opt), 5.6.47 (dbg), 5.6.47 (opt), 5.7.29 (dbg), 5.7.29 (opt), 8.0.19 (dbg), 8.0.19 (opt)

Comment by Roel Van de Paar [ 2020-06-15 ]

Note to self; bug ID's opt/dbg

thd->lex->sql_command == SQLCOM_UPDATE|SIGABRT|check_fields|Multiupdate_prelocking_strategy::handle_end|mysql_multi_update_prepare|mysql_execute_command  # DBG
 
SIGSEGV|check_fields|Multiupdate_prelocking_strategy::handle_end|mysql_multi_update_prepare|mysql_execute_command  # OPT

Comment by Oleksandr Byelkin [ 2020-10-19 ]

As we agreed it shoud issue error about version implementation limitations

Comment by Oleksandr Byelkin [ 2020-10-27 ]

OK to push after cosmetic fix of the test we agreed on

Generated at Thu Feb 08 09:17:36 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.