[MDEV-22525] Backport MDEV-19848 (Server crashes in check_vcol_forward_refs upon INSERT DELAYED into table with long blob key) Created: 2020-05-11  Updated: 2023-09-24  Resolved: 2023-09-24

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Insert, Server
Affects Version/s: 10.4
Fix Version/s: 10.4.26, 10.5.17, 10.6.9

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

Issue Links:
Relates
relates to MDEV-26986 LeakSanitizer/Valgrind errors in Bina... Closed
relates to MDEV-28012 Spider: SIGSEGV in check_vcol_forward... Closed
relates to MDEV-19848 Server crashes in check_vcol_forward_... Closed
relates to MDEV-27894 Spider: SIGSEGV in __memmove_avx_unal... Closed

 Description   

MDEV-19848 was created for 10.4+, but Monty only fixed it in 10.5 and closed. It's a non-debug crash with a very simple scenario, it needs to be fixed in 10.4. Please backport if applicable, or re-fix in 10.4.

CREATE  TABLE t1 (a BLOB, UNIQUE(a)) ENGINE=MyISAM;
INSERT DELAYED t1 () VALUES ();
 
# Cleanup
 
DROP TABLE t1;

10.4 RelWithDebInfo 6adb0d2f

#3  <signal handler called>
#4  0x000055b5f6a33e95 in check_vcol_forward_refs (field=field@entry=0x7fea4c012318, vcol=<optimized out>, check_constraint=check_constraint@entry=false) at /data/src/10.4/sql/table.cc:3471
#5  0x000055b5f6a3b475 in parse_vcol_defs (thd=thd@entry=0x7fea4c0009a8, mem_root=0x7fea4c006188, table=table@entry=0x7fea4c0113d0, error_reported=error_reported@entry=0x7fea5d28c350, mode=mode@entry=VCOL_INIT_DEPENDENCY_FAILURE_IS_WARNING) at /data/src/10.4/sql/table.cc:1284
#6  0x000055b5f695ebb2 in Delayed_insert::get_local_table (this=this@entry=0x7fea4c0d1008, client_thd=client_thd@entry=0x7fea4c0009a8) at /data/src/10.4/sql/sql_insert.cc:2651
#7  0x000055b5f6962a12 in delayed_get_table (grl_protection_request=0x7fea5d28c530, table_list=<optimized out>, thd=0x55b5f7a9baa0 <LOCK_delayed_insert>) at /data/src/10.4/sql/sql_insert.cc:2481
#8  open_and_lock_for_insert_delayed (table_list=<optimized out>, thd=0x55b5f7a9baa0 <LOCK_delayed_insert>) at /data/src/10.4/sql/sql_insert.cc:573
#9  mysql_insert (thd=thd@entry=0x7fea4c0009a8, table_list=<optimized out>, fields=..., values_list=..., update_fields=..., update_values=..., duplic=<optimized out>, ignore=<optimized out>) at /data/src/10.4/sql/sql_insert.cc:759
#10 0x000055b5f699004a in mysql_execute_command (thd=thd@entry=0x7fea4c0009a8) at /data/src/10.4/sql/sql_parse.cc:4528
#11 0x000055b5f6994c69 in mysql_parse (thd=thd@entry=0x7fea4c0009a8, rawbuf=<optimized out>, length=30, parser_state=parser_state@entry=0x7fea5d28e5b0, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /data/src/10.4/sql/sql_parse.cc:7900
#12 0x000055b5f6996e5f in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x7fea4c0009a8, packet=packet@entry=0x7fea4c007a19 "INSERT DELAYED t1 () VALUES ()", packet_length=packet_length@entry=30, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /data/src/10.4/sql/sql_parse.cc:1842
#13 0x000055b5f69985d1 in do_command (thd=0x7fea4c0009a8) at /data/src/10.4/sql/sql_parse.cc:1360
#14 0x000055b5f6a67e04 in do_handle_one_connection (connect=connect@entry=0x55b5f8f89fe8) at /data/src/10.4/sql/sql_connect.cc:1412
#15 0x000055b5f6a67eb4 in handle_one_connection (arg=arg@entry=0x55b5f8f89fe8) at /data/src/10.4/sql/sql_connect.cc:1316
#16 0x000055b5f700aec4 in pfs_spawn_thread (arg=0x55b5f8f02f38) at /data/src/10.4/storage/perfschema/pfs.cc:1869
#17 0x00007fea6506f4a4 in start_thread (arg=0x7fea5d28f700) at pthread_create.c:456
#18 0x00007fea631a3d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97



 Comments   
Comment by Roel Van de Paar [ 2020-08-14 ]

I am seeing this also, exact same.

USE test;
CREATE TABLE t (c BLOB, UNIQUE(c)) ENGINE=MyISAM;
INSERT DELAYED INTO t VALUES (1);

Leads to:

10.4.15 eae968f62d285de97ed607c87bc131cd863d5d03 (Debug)

Core was generated by `/test/MD110820-mariadb-10.4.15-linux-x86_64-dbg/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 0x152df13ce700 (LWP 2077010))]
(gdb) bt
#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=11) at ../sysdeps/unix/sysv/linux/pthread_kill.c:57
#1  0x00005567b9c2f8a6 in my_write_core (sig=sig@entry=11) at /test/10.4_dbg/mysys/stacktrace.c:482
#2  0x00005567b93abcdc in handle_fatal_signal (sig=11) at /test/10.4_dbg/sql/signal_handler.cc:343
#3  <signal handler called>
#4  0x00005567b91e5890 in check_vcol_forward_refs (field=field@entry=0x152dc9c6f690, vcol=0x152dc9c6f768, check_constraint=check_constraint@entry=false) at /test/10.4_dbg/sql/table.cc:3500
#5  0x00005567b91eed21 in parse_vcol_defs (thd=thd@entry=0x152dc9c15070, mem_root=0x152dc9c1aa10, table=table@entry=0x152dc9c6e748, error_reported=error_reported@entry=0x152df13cad10, mode=mode@entry=VCOL_INIT_DEPENDENCY_FAILURE_IS_WARNING) at /test/10.4_dbg/sql/table.cc:1299
#6  0x00005567b90bb13a in Delayed_insert::get_local_table (this=this@entry=0x152dc9c9a070, client_thd=client_thd@entry=0x152dc9c15070) at /test/10.4_dbg/sql/sql_insert.cc:2655
#7  0x00005567b90c277d in delayed_get_table (table_list=0x152dc9c6d178, grl_protection_request=0x152df13cb040, thd=0x152dc9c15070) at /test/10.4_dbg/sql/sql_insert.cc:2485
#8  open_and_lock_for_insert_delayed (table_list=0x152dc9c6d178, thd=0x152dc9c15070) at /test/10.4_dbg/sql/sql_insert.cc:573
#9  mysql_insert (thd=thd@entry=0x152dc9c15070, table_list=0x152dc9c6d178, fields=@0x152dc9c19e48: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x5567ba878000 <end_of_list>, last = 0x152dc9c19e48, elements = 0}, <No data fields>}, values_list=@0x152dc9c19e90: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x152dc9c6dd68, last = 0x152dc9c6dd68, elements = 1}, <No data fields>}, update_fields=@0x152dc9c19e78: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x5567ba878000 <end_of_list>, last = 0x152dc9c19e78, elements = 0}, <No data fields>}, update_values=@0x152dc9c19e60: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x5567ba878000 <end_of_list>, last = 0x152dc9c19e60, elements = 0}, <No data fields>}, duplic=<optimized out>, ignore=<optimized out>) at /test/10.4_dbg/sql/sql_insert.cc:759
#10 0x00005567b90fba63 in mysql_execute_command (thd=thd@entry=0x152dc9c15070) at /test/10.4_dbg/sql/sql_parse.cc:4519
#11 0x00005567b9103090 in mysql_parse (thd=thd@entry=0x152dc9c15070, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x152df13cd460, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /test/10.4_dbg/sql/sql_parse.cc:7896
#12 0x00005567b9105920 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x152dc9c15070, packet=packet@entry=0x152dc9c57071 "INSERT DELAYED INTO t VALUES (1)", packet_length=packet_length@entry=32, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /test/10.4_dbg/sql/sql_parse.cc:1834
#13 0x00005567b910935b in do_command (thd=0x152dc9c15070) at /test/10.4_dbg/sql/sql_parse.cc:1352
#14 0x00005567b92358b6 in do_handle_one_connection (connect=connect@entry=0x152dee035790) at /test/10.4_dbg/sql/sql_connect.cc:1412
#15 0x00005567b92359d6 in handle_one_connection (arg=0x152dee035790) at /test/10.4_dbg/sql/sql_connect.cc:1316
#16 0x0000152df05cc6db in start_thread (arg=0x152df13ce700) at pthread_create.c:463
#17 0x0000152def746a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Bug confirmed present in:
MariaDB: 10.4.15 (dbg), 10.4.15 (opt)

Bug confirmed not present in:
MariaDB: 10.1.47 (dbg), 10.1.47 (opt), 10.2.34 (dbg), 10.2.34 (opt), 10.3.25 (dbg), 10.3.25 (opt), 10.5.6 (dbg), 10.5.6 (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 Nayuta Yanagisawa (Inactive) [ 2022-03-07 ]

elenst Do you know the exact commit that fixed MDEV-19848? I could not find any commit whose commit message includes the keyword "MDEV-19848". It will help me with fixing MDEV-27894.

Comment by Elena Stepanova [ 2022-03-07 ]

This one would be my choice:

commit 4ef437558ae8a278f24726276bec57141db086da 736998cb75ba1d7bf8969329d649d9d1337353ff
Author:     Monty
AuthorDate: Mon Jan 13 18:30:13 2020 +0200
Commit:     Monty
CommitDate: Tue Mar 24 21:00:02 2020 +0200
 
    Improve update handler (long unique keys on blobs)

Comment by Nayuta Yanagisawa (Inactive) [ 2022-03-07 ]

Thank you very much!

Comment by Aleksey Midenkov [ 2023-09-24 ]

Does not reproduce in 10.4.32 b1ab4ec4e25:

CREATE  TABLE t1 (a BLOB, UNIQUE(a)) ENGINE=MyISAM;
INSERT DELAYED t1 () VALUES ();
DROP TABLE t1;
bug/vv.h                                 [ pass ]      3

Comment by Elena Stepanova [ 2023-09-24 ]

It was fixed by this patch:

commit 8911823f65a6557ce66ea5f8aecd55b115a85606
Author: Alexey Botchkov
Date:   Sat Jul 16 16:54:03 2022 +0400
 
    MDEV-26546 SIGSEGV's in spider_db_connect on SHOW TABLE and spider_db… …_mbase::connect (and SIGSEGV's in check_vcol_forward_refs and inline_mysql_mutex_lock)
    
    Not the SPIDER issue - happens to INSERT DELAYED.

According to git log it seems to be the only commit for MDEV-26546. Hopefully it was checked during the review that the fix had something to do with the original MDEV-26546 description, as by the look of it, it doesn't.
Otherwise it wouldn't be surprising if MDEV-26546 remained unfixed, it happens when a bug contains an assortment of unrelated test scenarios.

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