[MDEV-27668] Assertion `item->type_handler()->is_traditional_scalar_type() || item->type_handler() == type_handler()' failed in Field_inet6::can_optimize_keypart_ref Created: 2022-01-28  Updated: 2022-03-24  Resolved: 2022-03-10

Status: Closed
Project: MariaDB Server
Component/s: Data types
Affects Version/s: 10.5
Fix Version/s: 10.5.15

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Alexander Barkov
Resolution: Fixed Votes: 0
Labels: regression


 Description   

CREATE TABLE t1 (i INET6 PRIMARY KEY);
CREATE TABLE t2 (a VARCHAR(40) CHECK (JSON_VALID(a)));
 
# Inserts are optional, the failure happens either way
# INSERT INTO t1 VALUES ('::'),('ffff::ffff');
# INSERT INTO t2 VALUES ('{}'),('[]');
 
SELECT * FROM t1 JOIN t2 ON (i = a);
 
# Cleanup
DROP TABLE t1, t2;

10.5 430d60d1

mariadbd: /data/src/10.5/plugin/type_inet/sql_type_inet.cc:940: virtual bool Field_inet6::can_optimize_keypart_ref(const Item_bool_func*, const Item*) const: Assertion `item->type_handler()->is_traditional_scalar_type() || item->type_handler() == type_handler()' failed.
220128 17:57:42 [ERROR] mysqld got signal 6 ;
 
#7  0x00007f499cbee662 in __GI___assert_fail (assertion=0x55cd0f35f948 "item->type_handler()->is_traditional_scalar_type() || item->type_handler() == type_handler()", file=0x55cd0f35f240 "/data/src/10.5/plugin/type_inet/sql_type_inet.cc", line=940, function=0x55cd0f35f9a8 "virtual bool Field_inet6::can_optimize_keypart_ref(const Item_bool_func*, const Item*) const") at assert.c:101
#8  0x000055cd0ed35e27 in Field_inet6::can_optimize_keypart_ref (this=0x7f497c215630, cond=0x7f497c016ad0, item=0x7f497c016990) at /data/src/10.5/plugin/type_inet/sql_type_inet.cc:940
#9  0x000055cd0e093cb0 in add_key_part (keyuse_array=0x7f497c0180d0, key_field=0x7f497c0199a8) at /data/src/10.5/sql/sql_select.cc:6599
#10 0x000055cd0e094f70 in update_ref_and_keys (thd=0x7f497c000db8, keyuse=0x7f497c0180d0, join_tab=0x7f497c018918, tables=2, cond=0x7f497c016ad0, normal_tables=18446744073709551615, select_lex=0x7f497c0153a8, sargables=0x7f4993580468) at /data/src/10.5/sql/sql_select.cc:6953
#11 0x000055cd0e08f222 in make_join_statistics (join=0x7f497c017de0, tables_list=..., keyuse_array=0x7f497c0180d0) at /data/src/10.5/sql/sql_select.cc:5159
#12 0x000055cd0e084f6b in JOIN::optimize_inner (this=0x7f497c017de0) at /data/src/10.5/sql/sql_select.cc:2296
#13 0x000055cd0e082a1b in JOIN::optimize (this=0x7f497c017de0) at /data/src/10.5/sql/sql_select.cc:1668
#14 0x000055cd0e08de34 in mysql_select (thd=0x7f497c000db8, tables=0x7f497c0159b8, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7f497c017db8, unit=0x7f497c004f60, select_lex=0x7f497c0153a8) at /data/src/10.5/sql/sql_select.cc:4759
#15 0x000055cd0e07d8e9 in handle_select (thd=0x7f497c000db8, lex=0x7f497c004e98, result=0x7f497c017db8, setup_tables_done_option=0) at /data/src/10.5/sql/sql_select.cc:444
#16 0x000055cd0e040874 in execute_sqlcom_select (thd=0x7f497c000db8, all_tables=0x7f497c0159b8) at /data/src/10.5/sql/sql_parse.cc:6314
#17 0x000055cd0e037b93 in mysql_execute_command (thd=0x7f497c000db8) at /data/src/10.5/sql/sql_parse.cc:4005
#18 0x000055cd0e045655 in mysql_parse (thd=0x7f497c000db8, rawbuf=0x7f497c015300 "SELECT * FROM t1 JOIN t2 ON (i = a)", length=35, parser_state=0x7f4993581510, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:8100
#19 0x000055cd0e031766 in dispatch_command (command=COM_QUERY, thd=0x7f497c000db8, packet=0x7f497c00b5b9 "SELECT * FROM t1 JOIN t2 ON (i = a)", packet_length=35, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1891
#20 0x000055cd0e02ff7f in do_command (thd=0x7f497c000db8) at /data/src/10.5/sql/sql_parse.cc:1370
#21 0x000055cd0e1dc37b in do_handle_one_connection (connect=0x55cd11cb0d48, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1418
#22 0x000055cd0e1dc03d in handle_one_connection (arg=0x55cd11cfb378) at /data/src/10.5/sql/sql_connect.cc:1312
#23 0x000055cd0e6eb6ea in pfs_spawn_thread (arg=0x55cd11d3a938) at /data/src/10.5/storage/perfschema/pfs.cc:2201
#24 0x00007f499d0baea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#25 0x00007f499ccb7def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

The failure started happening after this commit in 10.5:

commit e4b302e436c0a1e0d477a8e8e8e513112fd3ec7f
Author: Alexander Barkov <bar@mariadb.com>
Date:   Mon Jan 10 18:05:55 2022 +0400
 
    MDEV-27018 IF and COALESCE lose "json" property
    
    Hybrid functions (IF, COALESCE, etc) did not preserve the JSON property

Reproducible with at least InnoDB, MyISAM, Aria.
No obvious immediate problem on a non-debug build.



 Comments   
Comment by Elena Stepanova [ 2022-01-28 ]

Raised the priority since it's a recent regression in the upcoming release. However, it's a debug assertion, so may be not necessarily a blocker.

Comment by Alexander Barkov [ 2022-01-28 ]

A similar crash happens inside Field_inet6::can_optimize_range() with this script:

DROP TABLE IF EXISTS t1;
CREATE TABLE t1 (i INET6 PRIMARY KEY);
SELECT * FROM t1 WHERE i<JSON_OBJECT('c','b');

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