Details
Description
This was found as part of MDEV-33478. See MDEV-33478 description for details.
This is fairly old code, why did new MSAN find it while valgrind didn't? It seems the cause was that the value was copied between Item objects but was not used.
If I add a printout:
diff --git a/sql/item_cmpfunc.cc b/sql/item_cmpfunc.cc
|
index f8fd28aebb5..7ec7a752875 100644
|
--- a/sql/item_cmpfunc.cc
|
+++ b/sql/item_cmpfunc.cc
|
@@ -5076,6 +5076,7 @@ Item_cond::fix_fields(THD *thd, Item **ref)
|
with_flags|= item->with_flags;
|
}
|
(void) eval_not_null_tables((void*) 0);
|
+ fprintf(stderr, "AAQ: not_null_tables_cache=%llx\n", not_null_tables_cache);
|
|
/*
|
We have to set fixed as some other items will check it and fail if we |
the attached testcase (extract from include/common-tests.inc) starts to fail under valgrind:
==23601== Thread 6:
|
==23601== Use of uninitialised value of size 8
|
==23601== at 0x747F7E1: _itoa_word (_itoa.c:180)
|
==23601== by 0x7482EDD: vfprintf (vfprintf.c:1642)
|
==23601== by 0x748563F: buffered_vfprintf (vfprintf.c:2329)
|
==23601== by 0x74826F5: vfprintf (vfprintf.c:1301)
|
==23601== by 0x748BE13: fprintf (fprintf.c:32)
|
==23601== by 0xE9C878: Item_cond::fix_fields(THD*, Item**) (item_cmpfunc.cc:5079)
|
==23601== by 0xB18FC8: make_cond_for_table_from_pred(THD*, Item*, Item*, unsigned long long, unsigned long long, int, bool, bool, bool) (sql_select.cc:23938)
|
==23601== by 0xB18CBC: make_cond_for_table(THD*, Item*, unsigned long long, unsigned long long, int, bool, bool) (sql_select.cc:23869)
|
==23601== by 0xAFA17A: make_join_select(JOIN*, SQL_SELECT*, Item*) (sql_select.cc:12543)
|
==23601== by 0xADC64D: JOIN::optimize_stage2() (sql_select.cc:2855)
|
==23601== by 0xADB459: JOIN::optimize_inner() (sql_select.cc:2590)
|
==23601== by 0xAD8A6D: JOIN::optimize() (sql_select.cc:1888)
|
==23601== by 0xAE4A58: mysql_select(THD*, TABLE_LIST*, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) (sql_select.cc:5127)
|
==23601== by 0xAD3452: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:559)
|
==23601== by 0xA91440: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:6372)
|
Attachments
Issue Links
- is part of
-
MDEV-33478 Tests massively fail with clang-18 -fsanitize=memory
-
- Closed
-
Previously suggested fix
diff --git a/sql/item_func.cc b/sql/item_func.ccindex 0973d0c2c82..54f7eb222bf 100644--- a/sql/item_func.cc+++ b/sql/item_func.cc@@ -397,6 +397,7 @@ Item_func::quick_fix_field()}}base_flags|= item_base_t::FIXED;+ eval_not_null_tables(NULL);}removes the error, but is it correct? quick_fix_field() just marks the item as fixed, without updating any fields (like e.g. used_tables). Why should we single out not_null_tables_cache and just update it?
Some callers update some fields after quick_fix_field() call:
new_cond->quick_fix_field();new_cond->used_tables_cache=((Item_cond_and*) cond)->used_tables_cache &tables;