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

Assertion `inited == NONE || table->open_by_handler' failed or Direct leak in init_dynamic_array2 upon INSERT .. RETURNING, and memory leak in init_dynamic_array2

    XMLWordPrintable

Details

    Description

      CREATE TABLE t (a INT, KEY (a));
      INSERT INTO t VALUES (1),(2);
       
      CREATE TABLE t1 (f INT);
       
      INSERT INTO t1 SELECT a FROM t WHERE 1 NOT IN (SELECT a FROM t) RETURNING f;
       
      # Cleanup
      DROP TABLE t, t1;
      

      10.5 5dbea46c

      mariadbd: /data/src/10.5/sql/handler.cc:6652: int handler::ha_external_lock(THD*, int): Assertion `inited == NONE || table->open_by_handler' failed.
      210318 15:41:20 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007f0d850def36 in __GI___assert_fail (assertion=0x55d53ed42040 "inited == NONE || table->open_by_handler", file=0x55d53ed3ef25 "/data/src/10.5/sql/handler.cc", line=6652, function=0x55d53ed41f30 "int handler::ha_external_lock(THD*, int)") at assert.c:101
      #8  0x000055d53e10fa6c in handler::ha_external_lock (this=0x7f0d6405a6f0, thd=0x7f0d64000db8, lock_type=2) at /data/src/10.5/sql/handler.cc:6652
      #9  0x000055d53dea1062 in handler::ha_external_unlock (this=0x7f0d6405a6f0, thd=0x7f0d64000db8) at /data/src/10.5/sql/handler.h:3421
      #10 0x000055d53e257526 in unlock_external (thd=0x7f0d64000db8, table=0x7f0d64019318, count=1) at /data/src/10.5/sql/lock.cc:727
      #11 0x000055d53e25683c in mysql_unlock_tables (thd=0x7f0d64000db8, sql_lock=0x7f0d640192b8, free_lock=false) at /data/src/10.5/sql/lock.cc:432
      #12 0x000055d53e256789 in mysql_unlock_tables (thd=0x7f0d64000db8, sql_lock=0x7f0d640192b8) at /data/src/10.5/sql/lock.cc:415
      #13 0x000055d53dce1b3c in close_thread_tables (thd=0x7f0d64000db8) at /data/src/10.5/sql/sql_base.cc:911
      #14 0x000055d53dd9a72e in mysql_execute_command (thd=0x7f0d64000db8) at /data/src/10.5/sql/sql_parse.cc:6116
      #15 0x000055d53dda0298 in mysql_parse (thd=0x7f0d64000db8, rawbuf=0x7f0d640152f0 "INSERT INTO t1 SELECT a FROM t WHERE 1 NOT IN (SELECT a FROM t) RETURNING f", length=75, parser_state=0x7f0d8029b510, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:8089
      #16 0x000055d53dd8c177 in dispatch_command (command=COM_QUERY, thd=0x7f0d64000db8, packet=0x7f0d6400b5a9 "", packet_length=75, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1889
      #17 0x000055d53dd8a96b in do_command (thd=0x7f0d64000db8) at /data/src/10.5/sql/sql_parse.cc:1370
      #18 0x000055d53df39097 in do_handle_one_connection (connect=0x55d541e0bd38, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1410
      #19 0x000055d53df38dfa in handle_one_connection (arg=0x55d541d15758) at /data/src/10.5/sql/sql_connect.cc:1312
      #20 0x000055d53e49a29b in pfs_spawn_thread (arg=0x55d541e0b968) at /data/src/10.5/storage/perfschema/pfs.cc:2201
      #21 0x00007f0d855f6609 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #22 0x00007f0d851ca293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      Non-debug build doesn't crash for me; however, non-debug ASAN build returns a LeakSanitizer error. I don't know whether it is related to the above, or a separate issue:

      10.5 5dbea46c non-debug ASAN

      ==3788701==ERROR: LeakSanitizer: detected memory leaks
       
      Direct leak of 1784 byte(s) in 1 object(s) allocated from:
          #0 0x7f8aad285bc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
          #1 0x5560082a851c in my_malloc /data/src/10.5/mysys/my_malloc.c:90
          #2 0x55600825ea80 in init_dynamic_array2 /data/src/10.5/mysys/array.c:71
          #3 0x55600696ce40 in JOIN::reoptimize(Item*, unsigned long long, JOIN::Join_plan_state*) /data/src/10.5/sql/sql_select.cc:28135
          #4 0x556006c917ad in JOIN::choose_subquery_plan(unsigned long long) /data/src/10.5/sql/opt_subselect.cc:6513
          #5 0x55600698b8fe in make_join_statistics /data/src/10.5/sql/sql_select.cc:5649
          #6 0x55600698b8fe in JOIN::optimize_inner() /data/src/10.5/sql/sql_select.cc:2256
          #7 0x55600698d41c in JOIN::optimize() /data/src/10.5/sql/sql_select.cc:1628
          #8 0x556007200b1e in subselect_single_select_engine::exec() /data/src/10.5/sql/item_subselect.cc:3932
          #9 0x5560071ff642 in Item_subselect::exec() /data/src/10.5/sql/item_subselect.cc:806
          #10 0x5560071ffa78 in Item_in_subselect::val_bool() /data/src/10.5/sql/item_subselect.cc:1865
          #11 0x556007005883 in Item_in_optimizer::val_int() /data/src/10.5/sql/item_cmpfunc.cc:1650
          #12 0x556007005883 in Item_in_optimizer::val_int() /data/src/10.5/sql/item_cmpfunc.cc:1558
          #13 0x556006f57e26 in Item_cache_int::cache_value() /data/src/10.5/sql/item.cc:9907
          #14 0x556006fc35e0 in Item_cache_wrapper::cache() /data/src/10.5/sql/item.cc:8693
          #15 0x556006fabd87 in Item_cache_wrapper::val_bool() /data/src/10.5/sql/item.cc:8879
          #16 0x556006fabd87 in Item_cache_wrapper::val_bool() /data/src/10.5/sql/item.cc:8862
          #17 0x556006fd4c65 in Item_func_not::val_int() /data/src/10.5/sql/item_cmpfunc.cc:202
          #18 0x556006993787 in JOIN::exec_inner() /data/src/10.5/sql/sql_select.cc:4363
          #19 0x556006995fd6 in JOIN::exec() /data/src/10.5/sql/sql_select.cc:4247
          #20 0x55600698d7d5 in mysql_select(THD*, TABLE_LIST*, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) /data/src/10.5/sql/sql_select.cc:4723
          #21 0x55600699031f in handle_select(THD*, LEX*, select_result*, unsigned long) /data/src/10.5/sql/sql_select.cc:417
          #22 0x556006829c1e in mysql_execute_command(THD*) /data/src/10.5/sql/sql_parse.cc:4769
          #23 0x5560067e49ec in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /data/src/10.5/sql/sql_parse.cc:8089
          #24 0x556006812fa8 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /data/src/10.5/sql/sql_parse.cc:1889
          #25 0x556006818e51 in do_command(THD*) /data/src/10.5/sql/sql_parse.cc:1370
          #26 0x556006bba62c in do_handle_one_connection(CONNECT*, bool) /data/src/10.5/sql/sql_connect.cc:1410
          #27 0x556006bbb1c4 in handle_one_connection /data/src/10.5/sql/sql_connect.cc:1312
          #28 0x5560077aedf8 in pfs_spawn_thread /data/src/10.5/storage/perfschema/pfs.cc:2201
          #29 0x7f8aacd35608 in start_thread /build/glibc-eX1tMB/glibc-2.31/nptl/pthread_create.c:477
       
      SUMMARY: AddressSanitizer: 1784 byte(s) leaked in 1 allocation(s).
      210318 15:44: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.10-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
      ??:0(__interceptor_tcgetattr)[0x7f8aad1e4d30]
      mysys/stacktrace.c:213(my_print_stacktrace)[0x5560082b1a86]
      sql/signal_handler.cc:209(handle_fatal_signal)[0x556006f14924]
      sigaction.c:0(__restore_rt)[0x7f8aacd413c0]
      ??:0(gsignal)[0x7f8aac82d18b]
      ??:0(abort)[0x7f8aac80c859]
      ??:0(__sanitizer_set_report_fd)[0x7f8aad2a36a2]
      ??:0(__sanitizer_get_module_and_offset_for_pc)[0x7f8aad2ae24c]
      ??:0(__lsan_do_recoverable_leak_check)[0x7f8aad2b3b9c]
      ??:0(__lsan_enable)[0x7f8aad2b33dd]
      ??:0(__cxa_finalize)[0x7f8aac83115e]
      /lib/x86_64-linux-gnu/libasan.so.5(+0x22be7)[0x7f8aad19abe7]
      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_DPd6/mysqld.1/data
      Resource Limits:
      Fatal signal 11 while backtracing
      

      Attachments

        Issue Links

          Activity

            People

              sanja Oleksandr Byelkin
              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.