[MDEV-12495] Conditional jump depends on uninitialised value for: SELECT NULL UNION geom_expression Created: 2017-04-13  Updated: 2017-04-22  Resolved: 2017-04-22

Status: Closed
Project: MariaDB Server
Component/s: GIS
Affects Version/s: 10.0, 10.1, 10.2, 10.3
Fix Version/s: 10.1.23, 10.0.31, 10.2.6, 10.3.1

Type: Bug Priority: Major
Reporter: Alexander Barkov Assignee: Alexey Botchkov
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-12560 Wrong data type for SELECT NULL UNION... Closed

 Description   

Valgrind reports an uninitialized value problem when running this query:

SELECT AsText(g) FROM (SELECT NULL AS g UNION SELECT Point(1,1)) AS t1;

==1322== Thread 6:
==1322== Conditional jump or move depends on uninitialised value(s)
==1322==    at 0x90FA60: Field_geom::geometry_type_merge(Field::geometry_type, Field::geometry_type) (field.cc:8605)
==1322==    by 0x959C1E: Item_type_holder::join_types(THD*, Item*) (item.cc:10184)
==1322==    by 0x7962EE: st_select_lex_unit::prepare(THD*, select_result*, unsigned long) (sql_union.cc:635)
==1322==    by 0x680FA4: mysql_derived_prepare(THD*, LEX*, TABLE_LIST*) (sql_derived.cc:726)
==1322==    by 0x67FFD6: mysql_handle_single_derived(LEX*, TABLE_LIST*, unsigned int) (sql_derived.cc:197)
==1322==    by 0x7BE93F: TABLE_LIST::handle_derived(LEX*, unsigned int) (table.cc:7729)
==1322==    by 0x6A10D0: st_select_lex::handle_derived(LEX*, unsigned int) (sql_lex.cc:3886)
==1322==    by 0x6F0311: JOIN::prepare(TABLE_LIST*, unsigned int, Item*, unsigned int, st_order*, bool, st_order*, Item*, st_order*, st_select_lex*, st_select_lex_unit*) (sql_select.cc:712)
==1322==    by 0x6FAA85: 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*) (sql_select.cc:3636)
==1322==    by 0x6EF4F6: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:373)
==1322==    by 0x6BACE8: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:6431)
==1322==    by 0x6B0A36: mysql_execute_command(THD*) (sql_parse.cc:3448)
==1322==    by 0x6BE670: mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) (sql_parse.cc:7874)
==1322==    by 0x6AC46F: dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) (sql_parse.cc:1812)
==1322==    by 0x6AADD8: do_command(THD*) (sql_parse.cc:1362)
==1322==    by 0x7FA697: do_handle_one_connection(CONNECT*) (sql_connect.cc:1354)

This patch fixes the problem:

--- a/sql/item.cc
+++ b/sql/item.cc
@@ -10035,7 +10035,8 @@ void Item_cache_row::set_null()
 Item_type_holder::Item_type_holder(THD *thd, Item *item)
   :Item(thd, item),
    Type_handler_hybrid_real_field_type(get_real_type(item)),
-   enum_set_typelib(0)
+   enum_set_typelib(0),
+   geometry_type(Field::GEOM_GEOMETRY)
 {
   DBUG_ASSERT(item->fixed);
   maybe_null= item->maybe_null;

However, one more related problem remains. Note, this script:

CREATE OR REPLACE TABLE t1 AS SELECT NULL AS g UNION SELECT Point(1,1);

creates a column of the GEOMETRY type, with and without the above patch. It should create a column of the POINT type instead.



 Comments   
Comment by Alexander Barkov [ 2017-04-13 ]

Alexey,

one of the options could be to fix only the valgrind problem in 10.0, 10.1, 10.2, then fix the GEOMETRY vs POINT problem in 10.3. I'm thinking of adding separate Type_handler_point, Type_handler_polygon, etc, for all geometry types. This should simplify the code and fix a number of other related problems:
MDEV-9405
MDEV-11303

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