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

LeakSanitizer: detected memory leaks in mem_heap_create_block_func / fts_optimize_create_msg

    XMLWordPrintable

Details

    Description

      --source include/have_innodb.inc
      --source include/have_sequence.inc
       
      CREATE TABLE t1 (
        id INT,
        pad CHAR(60),
        PRIMARY KEY (id),
        FULLTEXT KEY(pad)
      ) ENGINE=InnoDB;
       
      INSERT INTO t1 SELECT seq, CONCAT('s',seq) FROM seq_1_to_3000;
      ALTER IGNORE TABLE t1 ADD y INT, ALGORITHM=COPY;
       
      # Cleanup
      DROP TABLE t1;
      

      10.5 927a8823

      ==2670359==ERROR: LeakSanitizer: detected memory leaks
       
      Direct leak of 216 byte(s) in 1 object(s) allocated from:
          #0 0x7f27d68dcbc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
          #1 0x556d670dded4 in ut_allocator<unsigned char, true>::allocate(unsigned long, unsigned char const*, unsigned int, bool, bool) /data/src/10.5/storage/innobase/include/ut0new.h:377
          #2 0x556d672b3fdf in mem_heap_create_block_func(mem_block_info_t*, unsigned long, char const*, unsigned int, unsigned long) /data/src/10.5/storage/innobase/mem/mem0mem.cc:277
          #3 0x556d6787ea2d in mem_heap_create_func /data/src/10.5/storage/innobase/include/mem0mem.ic:375
          #4 0x556d6788cc29 in fts_optimize_create_msg /data/src/10.5/storage/innobase/fts/fts0opt.cc:2522
          #5 0x556d6788d9e0 in fts_optimize_request_sync_table(dict_table_t*) /data/src/10.5/storage/innobase/fts/fts0opt.cc:2657
          #6 0x556d678651f6 in fts_add_doc_by_id /data/src/10.5/storage/innobase/fts/fts0fts.cc:3536
          #7 0x556d67861105 in fts_add(fts_trx_table_t*, fts_trx_row_t*) /data/src/10.5/storage/innobase/fts/fts0fts.cc:2805
          #8 0x556d678625ec in fts_commit_table /data/src/10.5/storage/innobase/fts/fts0fts.cc:2977
          #9 0x556d67862776 in fts_commit(trx_t*) /data/src/10.5/storage/innobase/fts/fts0fts.cc:3026
          #10 0x556d675c7bce in trx_t::commit_low(mtr_t*) /data/src/10.5/storage/innobase/trx/trx0trx.cc:1512
          #11 0x556d675c7e3a in trx_t::commit() /data/src/10.5/storage/innobase/trx/trx0trx.cc:1564
          #12 0x556d675c88ec in trx_commit_for_mysql(trx_t*) /data/src/10.5/storage/innobase/trx/trx0trx.cc:1696
          #13 0x556d6706fa9b in innobase_commit_low(trx_t*) /data/src/10.5/storage/innobase/handler/ha_innodb.cc:4010
          #14 0x556d670701db in innobase_commit_ordered_2 /data/src/10.5/storage/innobase/handler/ha_innodb.cc:4116
          #15 0x556d67070cbb in innobase_commit /data/src/10.5/storage/innobase/handler/ha_innodb.cc:4220
          #16 0x556d66550854 in commit_one_phase_2 /data/src/10.5/sql/handler.cc:1941
          #17 0x556d6655055f in ha_commit_one_phase(THD*, bool) /data/src/10.5/sql/handler.cc:1920
          #18 0x556d6654e8af in ha_commit_trans(THD*, bool) /data/src/10.5/sql/handler.cc:1714
          #19 0x556d6656e905 in ha_enable_transaction(THD*, bool) /data/src/10.5/sql/handler.cc:5208
          #20 0x556d65ffa307 in mysql_trans_commit_alter_copy_data(THD*) /data/src/10.5/sql/sql_table.cc:11205
          #21 0x556d65ffd87f in copy_data_between_tables /data/src/10.5/sql/sql_table.cc:11568
          #22 0x556d65ff7583 in mysql_alter_table(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, HA_CREATE_INFO*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool, bool) /data/src/10.5/sql/sql_table.cc:10826
          #23 0x556d661956d9 in Sql_cmd_alter_table::execute(THD*) /data/src/10.5/sql/sql_alter.cc:539
          #24 0x556d65d56374 in mysql_execute_command(THD*) /data/src/10.5/sql/sql_parse.cc:6023
          #25 0x556d65d63e1d in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /data/src/10.5/sql/sql_parse.cc:8062
          #26 0x556d65d3a116 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /data/src/10.5/sql/sql_parse.cc:1889
          #27 0x556d65d36a3f in do_command(THD*) /data/src/10.5/sql/sql_parse.cc:1370
          #28 0x556d66179101 in do_handle_one_connection(CONNECT*, bool) /data/src/10.5/sql/sql_connect.cc:1410
          #29 0x556d66178a65 in handle_one_connection /data/src/10.5/sql/sql_connect.cc:1312
       
      SUMMARY: AddressSanitizer: 216 byte(s) leaked in 1 allocation(s).
      210126 15:52:57 [ERROR] mysqld got signal 6 ;
      This could be because you hit a bug. It is also possible that this binary
      or one of the libraries it was linked against is corrupt, improperly built,
      or misconfigured. This error can also be caused by malfunctioning hardware.
       
      To report this bug, see https://mariadb.com/kb/en/reporting-bugs
       
      We will try our best to scrape up some info that will hopefully help
      diagnose the problem, but since we have already crashed, 
      something is definitely wrong and this may fail.
       
      Server version: 10.5.9-MariaDB-debug-log
      read_buffer_size=131072
      max_used_connections=1
      thread_count=0
      Thread pointer: 0x0
      Attempting backtrace. You can use the following information to find out
      where mysqld died. If you see no messages after this, something went
      terribly wrong...
      stack_bottom = 0x0 thread_stack 0x5fc00
      ??:0(__interceptor_tcgetattr)[0x7f27d683bd30]
      mysys/stacktrace.c:212(my_print_stacktrace)[0x556d67b014b7]
      sql/signal_handler.cc:211(handle_fatal_signal)[0x556d66540e1a]
      sigaction.c:0(__restore_rt)[0x7f27d63fa3c0]
      ??:0(gsignal)[0x7f27d5ee818b]
      ??:0(abort)[0x7f27d5ec7859]
      ??:0(__sanitizer_set_report_fd)[0x7f27d68fa6a2]
      ??:0(__sanitizer_get_module_and_offset_for_pc)[0x7f27d690524c]
      ??:0(__lsan_do_recoverable_leak_check)[0x7f27d690ab9c]
      ??:0(__lsan_enable)[0x7f27d690a3dd]
      ??:0(__cxa_finalize)[0x7f27d5eec15e]
      /lib/x86_64-linux-gnu/libasan.so.5(+0x22be7)[0x7f27d67f1be7]
      The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
      information that should help you find out what is causing the crash.
      Writing a core file...
      Working directory at /dev/shm/var_auto_8zTy/mysqld.1/data
      Resource Limits:
      Fatal signal 11 while backtracing
      

      Valgrind version:

      ***Warnings generated in error logs during shutdown after running tests: bug2.mem1
       
      ==2670867== 14,688 bytes in 68 blocks are definitely lost in loss record 2 of 3
      ==2670867==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==2670867==    by 0x126E2D6: ut_allocator<unsigned char, true>::allocate(unsigned long, unsigned char const*, unsigned int, bool, bool) (ut0new.h:377)
      ==2670867==    by 0x1342A2E: mem_heap_create_block_func(mem_block_info_t*, unsigned long, char const*, unsigned int, unsigned long) (mem0mem.cc:277)
      ==2670867==    by 0x1644CA1: mem_heap_create_func(unsigned long, char const*, unsigned int, unsigned long) (mem0mem.ic:375)
      ==2670867==    by 0x164A6A2: fts_optimize_create_msg(fts_msg_type_t, void*) (fts0opt.cc:2522)
      ==2670867==    by 0x164AC83: fts_optimize_request_sync_table(dict_table_t*) (fts0opt.cc:2657)
      ==2670867==    by 0x163A23E: fts_add_doc_by_id(fts_trx_table_t*, unsigned long, ib_vector_t*) (fts0fts.cc:3536)
      ==2670867==    by 0x1638550: fts_add(fts_trx_table_t*, fts_trx_row_t*) (fts0fts.cc:2805)
      ==2670867==    by 0x1638D32: fts_commit_table(fts_trx_table_t*) (fts0fts.cc:2977)
      ==2670867==    by 0x1638E29: fts_commit(trx_t*) (fts0fts.cc:3026)
      ==2670867==    by 0x14DB2E9: trx_t::commit_low(mtr_t*) (trx0trx.cc:1512)
      ==2670867==    by 0x14DB462: trx_t::commit() (trx0trx.cc:1564)
      ==2670867==    by 0x14DB994: trx_commit_for_mysql(trx_t*) (trx0trx.cc:1696)
      ==2670867==    by 0x123EC84: innobase_commit_low(trx_t*) (ha_innodb.cc:4010)
      ==2670867==    by 0x123EFC2: innobase_commit_ordered_2(trx_t*, THD*) (ha_innodb.cc:4116)
      ==2670867==    by 0x123F53D: innobase_commit(handlerton*, THD*, bool) (ha_innodb.cc:4220)
      ==2670867==    by 0xDA11B9: commit_one_phase_2(THD*, bool, THD_TRANS*, bool) (handler.cc:1941)
      ==2670867==    by 0xDA10A8: ha_commit_one_phase(THD*, bool) (handler.cc:1920)
      ==2670867==    by 0xDA01E4: ha_commit_trans(THD*, bool) (handler.cc:1714)
      ==2670867==    by 0xDAC705: ha_enable_transaction(THD*, bool) (handler.cc:5208)
      ==2670867== 222,480 bytes in 1,030 blocks are definitely lost in loss record 3 of 3
      ==2670867==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==2670867==    by 0x126E2D6: ut_allocator<unsigned char, true>::allocate(unsigned long, unsigned char const*, unsigned int, bool, bool) (ut0new.h:377)
      ==2670867==    by 0x1342A2E: mem_heap_create_block_func(mem_block_info_t*, unsigned long, char const*, unsigned int, unsigned long) (mem0mem.cc:277)
      ==2670867==    by 0x1644CA1: mem_heap_create_func(unsigned long, char const*, unsigned int, unsigned long) (mem0mem.ic:375)
      ==2670867==    by 0x164A6A2: fts_optimize_create_msg(fts_msg_type_t, void*) (fts0opt.cc:2522)
      ==2670867==    by 0x164AC83: fts_optimize_request_sync_table(dict_table_t*) (fts0opt.cc:2657)
      ==2670867==    by 0x163A23E: fts_add_doc_by_id(fts_trx_table_t*, unsigned long, ib_vector_t*) (fts0fts.cc:3536)
      ==2670867==    by 0x1638550: fts_add(fts_trx_table_t*, fts_trx_row_t*) (fts0fts.cc:2805)
      ==2670867==    by 0x1638D32: fts_commit_table(fts_trx_table_t*) (fts0fts.cc:2977)
      ==2670867==    by 0x1638E29: fts_commit(trx_t*) (fts0fts.cc:3026)
      ==2670867==    by 0x14DB2E9: trx_t::commit_low(mtr_t*) (trx0trx.cc:1512)
      ==2670867==    by 0x14DB462: trx_t::commit() (trx0trx.cc:1564)
      ==2670867==    by 0x14DB994: trx_commit_for_mysql(trx_t*) (trx0trx.cc:1696)
      ==2670867==    by 0x123EC84: innobase_commit_low(trx_t*) (ha_innodb.cc:4010)
      ==2670867==    by 0x123EFC2: innobase_commit_ordered_2(trx_t*, THD*) (ha_innodb.cc:4116)
      ==2670867==    by 0x123F53D: innobase_commit(handlerton*, THD*, bool) (ha_innodb.cc:4220)
      ==2670867==    by 0xDA11B9: commit_one_phase_2(THD*, bool, THD_TRANS*, bool) (handler.cc:1941)
      ==2670867==    by 0xDA10A8: ha_commit_one_phase(THD*, bool) (handler.cc:1920)
      ==2670867==    by 0xDA01E4: ha_commit_trans(THD*, bool) (handler.cc:1714)
      ==2670867==    by 0xBEE8C5: trans_commit_stmt(THD*) (transaction.cc:472)
      

      The error started happening on 10.5 after this commit:

      commit bf1f9b59c7d0b619d8bf350b96436970c6edc118
      Author: Thirunarayanan Balathandayuthapani
      Date:   Thu Jan 21 18:32:48 2021 +0530
       
          MDEV-24638 Avoid repetitive FTS SYNC request for table
          
          fts_optimize_request_sync_table() can avoid the repetitive
          FTS SYNC request of the table if the table already has FTS_SYNC
          message in fts_optimize_wq queue.
      

      Attachments

        Issue Links

          Activity

            People

              thiru Thirunarayanan Balathandayuthapani
              elenst Elena Stepanova
              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.