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

Uninitialized field fts_token->position in innodb_fts.innodb_fts_plugin

Details

    Description

      http://buildbot.askmonty.org/buildbot/builders/xenial-amd64-valgrind/builds/183/steps/test/logs/stdio
      Also reproducible locally with cmake . -DCMAKE_BUILD_TYPE=Debug -DWITH_VALGRIND=YES

      innodb_fts.innodb_fts_plugin 'innodb'    w8 [ fail ]  Found warnings/errors in server log file!
      		 
              Test ended at 2016-12-22 12:31:59
      		 
      line
      		 
      ==21606== Thread 28:
      		 
      ==21606== Use of uninitialised value of size 8
      		 
      ==21606==    at 0x6EE9DCE: isprint (ctype.c:32)
      		 
      ==21606==    by 0xE7BD60: ut_print_buf(std::ostream&, void const*, unsigned long) (ut0ut.cc:471)
      		 
      ==21606==    by 0xF1CEBC: dfield_print(std::ostream&, dfield_t const*, unsigned long) (data0data.cc:542)
      		 
      ==21606==    by 0xD8C87A: rec_printer::rec_printer(dfield_t const*, unsigned long) (rem0rec.h:1082)
      		 
      ==21606==    by 0xD8184E: row_merge_buf_write(row_merge_buf_t const*, merge_file_t const*, unsigned char*) (row0merge.cc:1105)
      		 
      ==21606==    by 0xD588B8: fts_parallel_tokenization(void*) (row0ftsort.cc:989)
      		 
      ==21606==    by 0x64056F9: start_thread (pthread_create.c:333)
      		 
      ==21606==    by 0x6FC2B5C: clone (clone.S:109)
      		 
      ==21606== Use of uninitialised value of size 8
      		 
      ==21606==    at 0xE7BCBB: ut_print_buf_hex(std::ostream&, void const*, unsigned long) (ut0ut.cc:449)
      		 
      ==21606==    by 0xE7BD9D: ut_print_buf(std::ostream&, void const*, unsigned long) (ut0ut.cc:474)
      		 
      ==21606==    by 0xF1CEBC: dfield_print(std::ostream&, dfield_t const*, unsigned long) (data0data.cc:542)
      		 
      ==21606==    by 0xD8C87A: rec_printer::rec_printer(dfield_t const*, unsigned long) (rem0rec.h:1082)
      		 
      ==21606==    by 0xD8184E: row_merge_buf_write(row_merge_buf_t const*, merge_file_t const*, unsigned char*) (row0merge.cc:1105)
      		 
      ==21606==    by 0xD588B8: fts_parallel_tokenization(void*) (row0ftsort.cc:989)
      		 
      ==21606==    by 0x64056F9: start_thread (pthread_create.c:333)
      		 
      ==21606==    by 0x6FC2B5C: clone (clone.S:109)
      		 
      ==21606== Thread 29:
      		 
      ==21606== Conditional jump or move depends on uninitialised value(s)
      		 
      ==21606==    at 0xD4A10C: cmp_data(unsigned long, unsigned long, unsigned char const*, unsigned long, unsigned char const*, unsigned long) (rem0cmp.cc:505)
      		 
      ==21606==    by 0xD48AED: cmp_data_data(unsigned long, unsigned long, unsigned char const*, unsigned long, unsigned char const*, unsigned long) (rem0cmp.cc:655)
      		 
      ==21606==    by 0xD7D3E2: cmp_dfield_dfield(dfield_t const*, dfield_t const*) (rem0cmp.ic:51)
      		 
      ==21606==    by 0xD81158: row_merge_tuple_cmp(unsigned long, unsigned long, mtuple_t const&, mtuple_t const&, row_merge_dup_t*) (row0merge.cc:985)
      		 
      ==21606==    by 0xD81386: row_merge_tuple_sort(unsigned long, unsigned long, row_merge_dup_t*, mtuple_t*, mtuple_t*, unsigned long, unsigned long) (row0merge.cc:1060)
      		 
      ==21606==    by 0xD8145B: row_merge_tuple_sort(unsigned long, unsigned long, row_merge_dup_t*, mtuple_t*, mtuple_t*, unsigned long, unsigned long) (row0merge.cc:1060)
      		 
      ==21606==    by 0xD816E5: row_merge_buf_sort(row_merge_buf_t*, row_merge_dup_t*) (row0merge.cc:1078)
      		 
      ==21606==    by 0xD58859: fts_parallel_tokenization(void*) (row0ftsort.cc:987)
      		 
      ==21606==    by 0x64056F9: start_thread (pthread_create.c:333)
      		 
      ==21606==    by 0x6FC2B5C: clone (clone.S:109)
      		 
      ==21606== Conditional jump or move depends on uninitialised value(s)
      		 
      ==21606==    at 0xD81160: row_merge_tuple_cmp(unsigned long, unsigned long, mtuple_t const&, mtuple_t const&, row_merge_dup_t*) (row0merge.cc:986)
      		 
      ==21606==    by 0xD81386: row_merge_tuple_sort(unsigned long, unsigned long, row_merge_dup_t*, mtuple_t*, mtuple_t*, unsigned long, unsigned long) (row0merge.cc:1060)
      		 
      ==21606==    by 0xD8145B: row_merge_tuple_sort(unsigned long, unsigned long, row_merge_dup_t*, mtuple_t*, mtuple_t*, unsigned long, unsigned long) (row0merge.cc:1060)
      		 
      ==21606==    by 0xD816E5: row_merge_buf_sort(row_merge_buf_t*, row_merge_dup_t*) (row0merge.cc:1078)
      		 
      ==21606==    by 0xD58859: fts_parallel_tokenization(void*) (row0ftsort.cc:987)
      		 
      ==21606==    by 0x64056F9: start_thread (pthread_create.c:333)
      		 
      ==21606==    by 0x6FC2B5C: clone (clone.S:109)

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-12072 Do not unnecessarily construct rec_printer objects in debug builds

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-12888 Remove unused field dict_index_t::is_ngram

          • Major - Major loss of function.
          • Closed

          Task - A task that needs to be done. MDEV-7069 Fix buildbot failures in main server trees

          • Major - Major loss of function.
          • Stalled

          Bug - A problem which impairs or prevents the functions of the product. MDEV-12636 SELECT UNION writes garbage tail of VARCHAR column into internal temporary table

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            marko Marko Mäkelä added a comment -

            The reason for this failure is that the last field in the index is completely uninitialized. This is a 32-bit FTS_DOC_ID field. There is an optimization in row_merge_create_fts_sort_index() that I think we should consider removing, and always use 64 bits.

            In MDEV-12072 I would make the rec_printer construction conditional. With that change, the record comparisons will still fail, as expected.

            marko Marko Mäkelä added a comment - The reason for this failure is that the last field in the index is completely uninitialized. This is a 32-bit FTS_DOC_ID field. There is an optimization in row_merge_create_fts_sort_index() that I think we should consider removing, and always use 64 bits. In MDEV-12072 I would make the rec_printer construction conditional. With that change, the record comparisons will still fail, as expected.
            marko Marko Mäkelä added a comment -

            In 10.2, HAVE_VALGRIND was renamed to HAVE_VALGRIND_MEMCHECK_H, but InnoDB was still looking for the old value. Once I fixed that, UNIV_MEM_ASSERT_RW() in dfield_dup() caught the cause of this error very quickly.

            The field fts_token->position is not initialized in row_merge_fts_doc_tokenize(). As noted in MDEV-12888, we cannot have that field without changing the fulltext parser plugin ABI to something that resembles the changes that were made in MySQL 5.7.

            marko Marko Mäkelä added a comment - In 10.2, HAVE_VALGRIND was renamed to HAVE_VALGRIND_MEMCHECK_H, but InnoDB was still looking for the old value. Once I fixed that, UNIV_MEM_ASSERT_RW() in dfield_dup() caught the cause of this error very quickly. The field fts_token->position is not initialized in row_merge_fts_doc_tokenize(). As noted in MDEV-12888 , we cannot have that field without changing the fulltext parser plugin ABI to something that resembles the changes that were made in MySQL 5.7.
            marko Marko Mäkelä added a comment -

            bb-10.2-marko

            marko Marko Mäkelä added a comment - bb-10.2-marko
            serg Sergei Golubchik added a comment -

            ok to push

            serg Sergei Golubchik added a comment - ok to push

            People

              marko Marko Mäkelä
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              5 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.