[MDEV-28598] Assertion `got_name == named_item_expected()' failed in Json_writer::on_start_object Created: 2022-05-17  Updated: 2023-11-28

Status: In Review
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10
Fix Version/s: 10.4, 10.5, 10.6

Type: Bug Priority: Major
Reporter: Alice Sherepa Assignee: Sergei Petrunia
Resolution: Unresolved Votes: 1
Labels: 11.0-sel

Issue Links:
PartOf
includes MDEV-31752 Assertion `got_name == named_item_exp... Stalled
Relates
relates to MDEV-27878 Assertion `got_name == named_item_exp... Open

 Description   

SET optimizer_trace='enabled=on';
CREATE TABLE t1 (a int);
INSERT INTO t1 VALUES (1),(2),(3);
 
SELECT * FROM t1 WHERE a IN (SELECT 1 a FROM t1 WHERE EXISTS (select 1));

bb-10.4-release 2ab6983e595ab994b1d8

Version: '10.4.25-MariaDB-debug-log'  
mysqld: /sql/my_json_writer.cc:42: void Json_writer::on_start_object(): Assertion `got_name == named_item_expected()' failed.
220517 16:06:33 [ERROR] mysqld got signal 6 ;
 
Server version: 10.4.25-MariaDB-debug-log
 
linux/raise.c:51(__GI_raise)[0x7f68795d97bb]
stdlib/abort.c:81(__GI_abort)[0x7f68795c4535]
intl/loadmsgcat.c:1177(_nl_load_domain)[0x7f68795c440f]
/lib/x86_64-linux-gnu/libc.so.6(+0x30102)[0x7f68795d2102]
sql/my_json_writer.cc:43(Json_writer::on_start_object())[0x55b2691cd506]
sql/my_json_writer.cc:53(Json_writer::start_object())[0x55b2691cbab2]
sql/my_json_writer.h:424(Json_writer_object::Json_writer_object(Json_writer*, char const*))[0x55b268ee437a]
sql/my_json_writer.h:429(Json_writer_object::Json_writer_object(THD*, char const*))[0x55b268ee43da]
sql/sql_select.cc:1864(JOIN::optimize_inner())[0x55b269016856]
sql/sql_select.cc:1661(JOIN::optimize())[0x55b269015e1d]
sql/item_subselect.cc:3978(subselect_single_select_engine::exec())[0x55b2693edaaa]
sql/item_subselect.cc:801(Item_subselect::exec())[0x55b2693e1155]
sql/item_subselect.cc:1760(Item_exists_subselect::val_int())[0x55b2693e4835]
sql/item_cmpfunc.cc:1565(Item_in_optimizer::val_int())[0x55b26934cc6c]
sql/sql_type.cc:4602(Type_handler_int_result::Item_val_bool(Item*) const)[0x55b2691f29e1]
sql/item.h:1466(Item::val_bool())[0x55b268ea7506]
sql/item.h:1474(Item::eval_const_cond())[0x55b2690661bb]
sql/item_cmpfunc.cc:4858(Item_cond::fix_fields(THD*, Item**))[0x55b2693589c3]
sql/item.h:965(Item::fix_fields_if_needed(THD*, Item**))[0x55b268eb3ec1]
sql/opt_subselect.cc:1922(convert_subq_to_sj(JOIN*, Item_in_subselect*))[0x55b2691b4b4a]
sql/opt_subselect.cc:1295(convert_join_subqueries_to_semijoins(JOIN*))[0x55b2691b2d27]
sql/sql_select.cc:1915(JOIN::optimize_inner())[0x55b269016af9]
sql/sql_select.cc:1661(JOIN::optimize())[0x55b269015e1d]
sql/sql_select.cc:4752(mysql_select(THD*, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*))[0x55b2690213f1]
sql/sql_select.cc:436(handle_select(THD*, LEX*, select_result*, unsigned long))[0x55b269010d08]
sql/sql_parse.cc:6465(execute_sqlcom_select(THD*, TABLE_LIST*))[0x55b268fd63c7]
sql/sql_parse.cc:3979(mysql_execute_command(THD*))[0x55b268fccb9d]
sql/sql_parse.cc:8011(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x55b268fda37b]
sql/sql_parse.cc:1876(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x55b268fc67e3]
sql/sql_parse.cc:1378(do_command(THD*))[0x55b268fc4ef0]
sql/sql_connect.cc:1420(do_handle_one_connection(CONNECT*))[0x55b269152d3f]
sql/sql_connect.cc:1317(handle_one_connection)[0x55b2691529e4]
perfschema/pfs.cc:1871(pfs_spawn_thread)[0x55b26969590e]
nptl/pthread_create.c:487(start_thread)[0x7f6879a91fa3]
x86_64/clone.S:97(clone)[0x7f687969aeff]
 
Query (0x7f6858014768): SELECT * FROM t1 WHERE a IN (SELECT 1 a FROM t1 WHERE EXISTS (select 1))



 Comments   
Comment by Oleg Smirnov [ 2022-06-01 ]

This assertion triggered on an attempt to write a piece of corrupt
JSON to the optimizer trace:
"transformation": {
"select_id": 2,
"from": "IN (SELECT)",
"to": "semijoin",
{
"join_optimization":

{ "select_id": 3, "steps": [] }

}

This happened because some parts of the query may be evaluated right
during the optimization stage. To handle such cases Json_writer will now
implicitly add named members with automatically assigned names
"implicitly_added_member_#1", "implicitly_added_member_#2", etc
to preserve JSON document correctness. Also the tail of the JSON document
will be printed to stderr before abort.
Those two improvements only apply for Debug builds, not for Release ones
as the Release builds skip JSON correctness checks

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