[MDEV-14259] Reference to wrong memory when running main.win with valgrind Created: 2017-11-02  Updated: 2019-05-04  Resolved: 2019-05-04

Status: Closed
Project: MariaDB Server
Component/s: Optimizer - Window functions
Affects Version/s: 10.2
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Michael Widenius Assignee: Vicențiu Ciorbaru
Resolution: Cannot Reproduce Votes: 0
Labels: None


 Description   

mysql-test-run --valgrind main.win gives the following error:

==7660== Thread 6:
==7660== Invalid read of size 4
==7660==    at 0x7447A7: JOIN::create_postjoin_aggr_table(st_join_table*, List<Item>*, st_order*, bool, bool, bool) (sql_select.cc:2858)
==7660==    by 0x7429FC: JOIN::make_aggr_tables_info() (sql_select.cc:2405)
==7660==    by 0x741CF5: JOIN::optimize_inner() (sql_select.cc:2183)
==7660==    by 0x73E024: JOIN::optimize() (sql_select.cc:1085)
==7660==    by 0x746E91: 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:3664)
==7660==    by 0x73B97E: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:373)
==7660==    by 0x70883A: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:6420)
==7660==    by 0x6FE8F4: mysql_execute_command(THD*) (sql_parse.cc:3454)
==7660==    by 0x70BFC0: mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) (sql_parse.cc:7861)
==7660==    by 0x6FA307: dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) (sql_parse.cc:1805)
==7660==    by 0x6F8CCC: do_command(THD*) (sql_parse.cc:1360)
==7660==    by 0x83F7F6: do_handle_one_connection(CONNECT*) (sql_connect.cc:1354)
==7660==    by 0x83F576: handle_one_connection (sql_connect.cc:1260)
==7660==    by 0x1168598: pfs_spawn_thread (pfs.cc:1863)
==7660==    by 0x4E3D0A3: start_thread (in /lib64/libpthread-2.19.so)
==7660==    by 0x6AD96EC: clone (in /lib64/libc-2.19.so)
==7660==  Address 0xcd4a44c is 44 bytes inside an unallocated block of size 304 in arena "client"

The code in question is:

    if (ordered_index_usage != ordered_index_group_by &&
        (join_tab + const_tables)->type != JT_CONST && // Don't sort 1 row
        !implicit_grouping &&
        add_sorting_to_table(join_tab + const_tables, group_list))
      goto err;

My guess is that there is no more tables after const_tables, so join_tab+ const_tables will point to an area outside of allocated memory.

Possible fix is to not do the test of const_tables == all_tables.
However, I don't understand why we are testing for JT_CONST at all.
All const tables should be first in join_tab, so there is no way that join_tab+const_tables could be of type JT_CONST.
What am I missing ?



 Comments   
Comment by Varun Gupta (Inactive) [ 2019-05-04 ]

Doesn't fail on 10.2 now, I think we can close it

==============================================================================
 
TEST                                      RESULT   TIME (ms) or COMMENT
--------------------------------------------------------------------------
 
worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
 main.win                                 [ pass ]  415667
valgrind_report                          [ pass ]       
--------------------------------------------------------------------------
The servers were restarted 0 times
Spent 415.667 of 440 seconds executing testcases

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