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

Direct leak in my_register_filename / binlog_online_alter_end_trans

    XMLWordPrintable

Details

    Description

      The test case is very non-deterministic. It currently fails for me fairly well, usually within ~10 attempts, but it is very volatile, so run with big enough --repeat=N. Also with --force-restart!

      REPEAT in the test case is not an important element of the scenario, it just helps with the timing. I'm not sure what role JSON_TABLE plays, possibly the same.

      CREATE TABLE t (f LONGBLOB DEFAULT NULL) ENGINE=MyISAM;
      INSERT INTO t VALUES (NULL);
       
      --connect (con1,localhost,root,,)
      --send
        ALTER TABLE t FORCE, ALGORITHM=COPY;
       
      --connection default
      INSERT INTO t SELECT REPEAT('a',130000) FROM JSON_TABLE(CONCAT('[',REPEAT('"a",',1000),'"a"]'), '$' COLUMNS (col1 FOR ORDINALITY)) AS u;
       
      --connection con1
      --reap
      DROP TABLE t;
      

      bb-11.0-oalter e599b8b458

      Warning: Memory not freed: 96
       
      =================================================================
      ==2695459==ERROR: LeakSanitizer: detected memory leaks
       
      Direct leak of 96 byte(s) in 1 object(s) allocated from:
          #0 0x7fb4becb89cf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
          #1 0x5584f23b5b6a in my_malloc /data/src/bb-11.0-oalter-asan/mysys/my_malloc.c:91
          #2 0x5584f23b6cfb in my_strdup /data/src/bb-11.0-oalter-asan/mysys/my_malloc.c:235
          #3 0x5584f23b8b32 in my_register_filename /data/src/bb-11.0-oalter-asan/mysys/my_open.c:140
          #4 0x5584f238eca8 in create_temp_file /data/src/bb-11.0-oalter-asan/mysys/mf_tempfile.c:128
          #5 0x5584f2356249 in real_open_cached_file /data/src/bb-11.0-oalter-asan/mysys/mf_cache.c:61
          #6 0x5584f2362b4d in my_b_flush_io_cache /data/src/bb-11.0-oalter-asan/mysys/mf_iocache.c:1706
          #7 0x5584f235ca73 in _my_b_write /data/src/bb-11.0-oalter-asan/mysys/mf_iocache.c:559
          #8 0x5584f235820d in my_b_write /data/src/bb-11.0-oalter-asan/include/my_sys.h:545
          #9 0x5584f236237f in my_b_safe_write /data/src/bb-11.0-oalter-asan/mysys/mf_iocache.c:1623
          #10 0x5584f13e97ae in Log_event_writer::write_internal(unsigned char const*, unsigned long) /data/src/bb-11.0-oalter-asan/sql/log_event_server.cc:766
          #11 0x5584f13eabbf in Log_event_writer::write_data(unsigned char const*, unsigned long) /data/src/bb-11.0-oalter-asan/sql/log_event_server.cc:869
          #12 0x5584f13b3897 in CacheWriter::write(unsigned char*, unsigned long) /data/src/bb-11.0-oalter-asan/sql/log.cc:7675
          #13 0x5584f1391157 in Event_log::write_cache(THD*, st_io_cache*) /data/src/bb-11.0-oalter-asan/sql/log.cc:7902
          #14 0x5584f138f857 in binlog_online_alter_end_trans /data/src/bb-11.0-oalter-asan/sql/log.cc:7711
          #15 0x5584f136d7d9 in binlog_commit(THD*, bool, bool) /data/src/bb-11.0-oalter-asan/sql/log.cc:2333
          #16 0x5584f1038b84 in commit_one_phase_2 /data/src/bb-11.0-oalter-asan/sql/handler.cc:2116
          #17 0x5584f10387e9 in ha_commit_one_phase(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/handler.cc:2078
          #18 0x5584f1036ab7 in ha_commit_trans(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/handler.cc:1872
          #19 0x5584f0c40b90 in trans_commit_stmt(THD*) /data/src/bb-11.0-oalter-asan/sql/transaction.cc:472
          #20 0x5584f075f608 in mysql_execute_command(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:6061
          #21 0x5584f076bd4c in mysql_parse(THD*, char*, unsigned int, Parser_state*) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:8000
          #22 0x5584f0741f44 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:1894
          #23 0x5584f073ec76 in do_command(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:1407
          #24 0x5584f0bfd039 in do_handle_one_connection(CONNECT*, bool) /data/src/bb-11.0-oalter-asan/sql/sql_connect.cc:1416
          #25 0x5584f0bfc9fa in handle_one_connection /data/src/bb-11.0-oalter-asan/sql/sql_connect.cc:1318
          #26 0x5584f17d8a37 in pfs_spawn_thread /data/src/bb-11.0-oalter-asan/storage/perfschema/pfs.cc:2201
          #27 0x7fb4be0a7fd3 in start_thread nptl/pthread_create.c:442
       
      SUMMARY: AddressSanitizer: 96 byte(s) leaked in 1 allocation(s).
      230329  0:36:08 [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: 11.0.1-MariaDB-debug-log source revision: e599b8b45867cd24720a9ecd4ba28500f579c5a4
      read_buffer_size=131072
      max_used_connections=2
      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 0x100000
      sanitizer_common/sanitizer_common_interceptors.inc:4277(__interceptor_backtrace.part.0)[0x7fb4bec51f31]
      mysys/stacktrace.c:215(my_print_stacktrace)[0x5584f23c6cd1]
      sql/signal_handler.cc:238(handle_fatal_signal)[0x5584f1027e24]
      libc_sigaction.c:0(__restore_rt)[0x7fb4be05af90]
      nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7fb4be0a9ccc]
      posix/raise.c:27(__GI_raise)[0x7fb4be05aef2]
      stdlib/abort.c:81(__GI_abort)[0x7fb4be045472]
      sanitizer_common/sanitizer_posix_libcdep.cpp:137(__sanitizer::Abort())[0x7fb4becd650f]
      sanitizer_common/sanitizer_termination.cpp:59(__sanitizer::Die())[0x7fb4bece2ba1]
      lsan/lsan_common_linux.cpp:120(__lsan::HandleLeaks())[0x7fb4becea87c]
      lsan/lsan_common.cpp:732(__lsan::DoLeakCheck())[0x7fb4bece8dc5]
      stdlib/cxa_finalize.c:84(__cxa_finalize)[0x7fb4be05cf37]
      crtstuff.c:0(__do_global_dtors_aux)[0x7fb4bec24bc7]
      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 /mnt8t/src/bb-11.0-oalter-asan/mysql-test/var/mysqld.1/data
      Resource Limits:
      Limit                     Soft Limit           Hard Limit           Units     
      Max cpu time              unlimited            unlimited            seconds   
      Max file size             unlimited            unlimited            bytes     
      Max data size             unlimited            unlimited            bytes     
      Max stack size            8388608              unlimited            bytes     
      Max core file size        unlimited            unlimited            bytes     
      Max resident set          unlimited            unlimited            bytes     
      Max processes             385809               385809               processes 
      Max open files            1024                 1024                 files     
      Max locked memory         12649951232          12649951232          bytes     
      Max address space         unlimited            unlimited            bytes     
      Max file locks            unlimited            unlimited            locks     
      Max pending signals       385809               385809               signals   
      Max msgqueue size         819200               819200               bytes     
      Max nice priority         0                    0                    
      Max realtime priority     0                    0                    
      Max realtime timeout      unlimited            unlimited            us        
      Core pattern: core
       
      Fatal signal 11 while backtracing
      

      Not reproducible on the baseline.

      Attachments

        Issue Links

          Activity

            People

              nikitamalyavin Nikita Malyavin
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              3 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.