Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-14259

Reference to wrong memory when running main.win with valgrind

    XMLWordPrintable

Details

    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 ?

      Attachments

        Activity

          People

            cvicentiu Vicențiu Ciorbaru
            monty Michael Widenius
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.