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

Test main.union causes valgrind warnings "blocks are definitely lost" in buildbot

    Details

      Description

      See
      http://buildbot.askmonty.org/buildbot/builders/work-amd64-valgrind/builds/4952/steps/test/logs/stdio

      The failure started happening on 5.3 tree with the following revision:

      revno: 3733 [merge]
      revision-id: igor@askmonty.org-20131205204004-10sjgp6dy3tb937b
      parent: sanja@askmonty.org-20131204145433-i54vkc1iwbgw41oz
      parent: igor@askmonty.org-20131205191320-pfja761po2x9p9ri
      committer: Igor Babaev <igor@askmonty.org>
      branch nick: maria-5.3
      timestamp: Thu 2013-12-05 12:40:04 -0800
      message:
        Merge
          ------------------------------------------------------------
          revno: 3731.1.1
          revision-id: igor@askmonty.org-20131205191320-pfja761po2x9p9ri
          committer: Igor Babaev <igor@askmonty.org>
          timestamp: Thu 2013-12-05 11:13:20 -0800
          message:
            Fixed bug mdev-5382
            When marking used columns the function find_field_in_table_ref() erroneously
            called the walk method for the real item behind a view/derived table field
            with the second parameter set to TRUE.
            This erroneous code was introduced in 2006. 

      perl mysql-test-run.pl main.union --valgrind-mysqld

      ***Warnings generated in error logs during shutdown after running tests: main.union
       
      ==15776== 8 bytes in 1 blocks are definitely lost in loss record 1 of 3
      ==15776==    at 0x4C25DD6: malloc (vg_replace_malloc.c:270)
      ==15776==    by 0xA9EEE9: my_malloc (my_malloc.c:42)
      ==15776==    by 0x7C0C3B: filesort(THD*, st_table*, st_sort_field*, unsigned int, SQL_SELECT*, unsigned long long, bool, unsigned long long*) (filesort.cc:1066)
      ==15776==    by 0x6F7946: create_sort_index(THD*, JOIN*, st_order*, unsigned long long, unsigned long long, bool) (sql_select.cc:19342)
      ==15776==    by 0x6FF3F1: JOIN::exec() (sql_select.cc:2731)
      ==15776==    by 0x83FB3D: st_select_lex_unit::exec() (sql_union.cc:787)
      ==15776==    by 0x5E68D6: subselect_union_engine::exec() (item_subselect.cc:3168)
      ==15776==    by 0x5E6DA2: Item_subselect::exec() (item_subselect.cc:588)
      ==15776==    by 0x5E5DDB: Item_singlerow_subselect::val_int() (item_subselect.cc:1155)
      ==15776==    by 0x5442DB: Item::send(Protocol*, String*) (item.cc:6080)
      ==15776==    by 0x63A72C: select_send::send_data(List<Item>&) (sql_class.cc:2012)
      ==15776==    by 0x6D818D: end_send(JOIN*, st_join_table*, bool) (sql_select.cc:17329)
      ==15776==    by 0x6DBFE4: evaluate_join_record(JOIN*, st_join_table*, int) (sql_select.cc:16469)
      ==15776==    by 0x6E8CDC: sub_select(JOIN*, st_join_table*, bool) (sql_select.cc:16311)
      ==15776==    by 0x6FE16C: do_select(JOIN*, List<Item>*, st_table*, Procedure*) (sql_select.cc:15924)
      ==15776==    by 0x6FF50C: JOIN::exec() (sql_select.cc:2788)

        Attachments

          Activity

            People

            • Assignee:
              igor Igor Babaev
              Reporter:
              elenst Elena Stepanova
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: