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

Memory leak errors upon running server with S3 engine enabled

    XMLWordPrintable

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL)
    • 10.5, 10.6
    • Storage Engine - S3
    • None

    Description

      When the server is started with S3 engine enabled, it throws LeakSanitizer/MSAN/Valgrind errors on shutdown. It doesn't matter whether S3 is fully configured or whether only plugin is loaded, and whether it was used or not.

      To reproduce, just start/shutdown the server with --plugin-load-add=ha_s3, or in case of MTR, run any test with --mysqld=--plugin-load-add=ha_s3, e.g.

      perl ./mtr main.1st --mysqld=--plugin-load-add=ha_s3
      

      Valgrind and LeakSanitizer return rather meaningless errors (below), MSAN is more readable:

      10.5 098c0f2634 MSAN

      Uninitialized bytes in __interceptor_strlen at offset 0 inside [0x7ffc3027a216, 1)
      ==12187==WARNING: MemorySanitizer: use-of-uninitialized-value
          #0 0x7fdb15ddc9cf  (/lib/x86_64-linux-gnu/libcurl.so.4+0x2a9cf)
          #1 0x7fdb15ddcc98 in curl_mvsnprintf (/lib/x86_64-linux-gnu/libcurl.so.4+0x2ac98)
          #2 0x7fdb15ddb712 in curl_msnprintf (/lib/x86_64-linux-gnu/libcurl.so.4+0x29712)
          #3 0x7fdb15ddaf54 in curl_version (/lib/x86_64-linux-gnu/libcurl.so.4+0x28f54)
          #4 0x7fdb15ddb09c  (/lib/x86_64-linux-gnu/libcurl.so.4+0x2909c)
          #5 0x7fdb15de29c5  (/lib/x86_64-linux-gnu/libcurl.so.4+0x309c5)
          #6 0x7fdb15e79cf5 in ms3_library_init_malloc /home/jenkins/10.5/storage/maria/libmarias3/src/marias3.c:117:7
          #7 0x7fdb15e62fa1 in ha_s3_init(void*) /home/jenkins/10.5/storage/maria/ha_s3.cc:1041:3
          #8 0x55ae03d6add5 in ha_initialize_handlerton(st_plugin_int*) /home/jenkins/10.5/sql/handler.cc:645:31
          #9 0x55ae0318f978 in plugin_initialize(st_mem_root*, st_plugin_int*, int*, char**, bool) /home/jenkins/10.5/sql/sql_plugin.cc:1461:9
          #10 0x55ae0318a04a in plugin_init(int*, char**, int) /home/jenkins/10.5/sql/sql_plugin.cc:1753:15
          #11 0x55ae02c86cbb in init_server_components() /home/jenkins/10.5/sql/mysqld.cc:4929:7
          #12 0x55ae02c86cbb in mysqld_main(int, char**) /home/jenkins/10.5/sql/mysqld.cc:5523:7
          #13 0x55ae02c767f3 in main /home/jenkins/10.5/sql/main.cc:25:10
          #14 0x7fdb1b88f0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
          #15 0x55ae02bf82dd in _start (/home/jenkins/10.5/sql/mariadbd+0x70c2dd)
       
        Uninitialized value was created by an allocation of 'key_name' in the stack frame of function 'handle_options'
          #0 0x55ae05f73450 in handle_options /home/jenkins/10.5/mysys/my_getopt.c:196
       
      SUMMARY: MemorySanitizer: use-of-uninitialized-value (/lib/x86_64-linux-gnu/libcurl.so.4+0x2a9cf) 
      

      10.5 be20b3b0 Valgrind

      ==3530231== 48 bytes in 6 blocks are still reachable in loss record 2 of 4
      ==3530231==    at 0x483877F: malloc (vg_replace_malloc.c:307)
      ==3530231==    by 0x543FA4D: ??? (in /usr/lib/x86_64-linux-gnu/libgcrypt.so.20.2.8)
      ==3530231==    by 0x544122B: ??? (in /usr/lib/x86_64-linux-gnu/libgcrypt.so.20.2.8)
      ==3530231==    by 0x550681F: ??? (in /usr/lib/x86_64-linux-gnu/libgcrypt.so.20.2.8)
      ==3530231==    by 0x543F999: ??? (in /usr/lib/x86_64-linux-gnu/libgcrypt.so.20.2.8)
      ==3530231==    by 0x5440BE0: ??? (in /usr/lib/x86_64-linux-gnu/libgcrypt.so.20.2.8)
      ==3530231==    by 0x543C788: gcry_control (in /usr/lib/x86_64-linux-gnu/libgcrypt.so.20.2.8)
      ==3530231==    by 0x9FE7F73: ???
      ==3530231==    by 0x9F3128A: ???
      ==3530231==    by 0x9ED8534: ???
      ==3530231==    by 0x9E9133D: ???
      ==3530231==    by 0x9E8CB1B: ???
      ==3530231==    by 0x9E89ACF: ???
      ==3530231==    by 0xCAEF5B: ha_initialize_handlerton(st_plugin_int*) (handler.cc:645)
      ==3530231==    by 0x903E62: plugin_initialize(st_mem_root*, st_plugin_int*, int*, char**, bool) (sql_plugin.cc:1459)
      ==3530231==    by 0x903631: plugin_init(int*, char**, int) (sql_plugin.cc:1751)
      ==3530231== 144 bytes in 6 blocks are still reachable in loss record 3 of 4
      ==3530231==    at 0x483877F: malloc (vg_replace_malloc.c:307)
      ==3530231==    by 0x543FA4D: ??? (in /usr/lib/x86_64-linux-gnu/libgcrypt.so.20.2.8)
      ==3530231==    by 0x544122B: ??? (in /usr/lib/x86_64-linux-gnu/libgcrypt.so.20.2.8)
      ==3530231==    by 0x5506812: ??? (in /usr/lib/x86_64-linux-gnu/libgcrypt.so.20.2.8)
      ==3530231==    by 0x543F999: ??? (in /usr/lib/x86_64-linux-gnu/libgcrypt.so.20.2.8)
      ==3530231==    by 0x5440BE0: ??? (in /usr/lib/x86_64-linux-gnu/libgcrypt.so.20.2.8)
      ==3530231==    by 0x543C788: gcry_control (in /usr/lib/x86_64-linux-gnu/libgcrypt.so.20.2.8)
      ==3530231==    by 0x9FE7F73: ???
      ==3530231==    by 0x9F3128A: ???
      ==3530231==    by 0x9ED8534: ???
      ==3530231==    by 0x9E9133D: ???
      ==3530231==    by 0x9E8CB1B: ???
      ==3530231==    by 0x9E89ACF: ???
      ==3530231==    by 0xCAEF5B: ha_initialize_handlerton(st_plugin_int*) (handler.cc:645)
      ==3530231==    by 0x903E62: plugin_initialize(st_mem_root*, st_plugin_int*, int*, char**, bool) (sql_plugin.cc:1459)
      ==3530231==    by 0x903631: plugin_init(int*, char**, int) (sql_plugin.cc:1751)
      

      10.5 098c0f26 ASAN

      ==3530310==ERROR: LeakSanitizer: detected memory leaks
       
      Direct leak of 144 byte(s) in 6 object(s) allocated from:
          #0 0x7fa881ed6e8f in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
          #1 0x7fa879746a4d  (<unknown module>)
          #2 0x9eebeb6612564aff  (<unknown module>)
       
      Indirect leak of 48 byte(s) in 6 object(s) allocated from:
          #0 0x7fa881ed6e8f in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
          #1 0x7fa879746a4d  (<unknown module>)
          #2 0x9eebeb6612564aff  (<unknown module>)
       
      SUMMARY: AddressSanitizer: 192 byte(s) leaked in 12 allocation(s).
      220728 21:12:41 [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.17-MariaDB-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
      sanitizer_common/sanitizer_common_interceptors.inc:4101(__interceptor_backtrace.part.0)[0x7fa881e70df1]
      mysys/stacktrace.c:213(my_print_stacktrace)[0x55725bc76946]
      sql/signal_handler.cc:232(handle_fatal_signal)[0x55725aaaad94]
      sigaction.c:0(__restore_rt)[0x7fa88194e140]
      linux/raise.c:51(__GI_raise)[0x7fa88147dce1]
      stdlib/abort.c:81(__GI_abort)[0x7fa881467537]
      sanitizer_common/sanitizer_posix_libcdep.cpp:149(__sanitizer::Abort())[0x7fa881ef211b]
      sanitizer_common/sanitizer_termination.cpp:59(__sanitizer::Die())[0x7fa881efcce8]
      lsan/lsan_common_linux.cpp:115(__lsan::HandleLeaks())[0x7fa881f02258]
      sanitizer_common/sanitizer_mutex.h:187(__sanitizer::GenericScopedLock<__sanitizer::BlockingMutex>::~GenericScopedLock())[0x7fa881f019d5]
      stdlib/cxa_finalize.c:84(__cxa_finalize)[0x7fa881480ac6]
      crtstuff.c:0(__do_global_dtors_aux)[0x7fa881e50c33]
      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/bld/10.5-rel-asan-nightly/mysql-test/var/mysqld.1/data
      Resource Limits:
      Fatal signal 11 while backtracing
      

      Attachments

        Activity

          People

            monty Michael Widenius
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:

              Git Integration

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