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

Server crashes in create_tmp_table / JOIN::create_postjoin_aggr_table

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Cannot Reproduce
    • 10.2(EOL)
    • N/A
    • Optimizer
    • None

    Description

      Note: I have no idea what it has to do with virtual columns, but I'm linking them because the crash started happening with this revision:

      commit a411d7f4f670c24b43b50f7d2a1129e10218f4a7
      Author: Sergei Golubchik <serg@mariadb.org>
      Date:   Mon Nov 7 17:17:40 2016 +0100
       
          store/show vcols as item->print()
          
          otherwise we'd need to store sql_mode *per vcol*
          (consider CREATE INDEX...) and how SHOW CREATE TABLE would
          support that?
          
          Additionally, get rid of vcol::expr_str, just to make sure
          the string is always generated and never leaked in the
          original form.
      

      I also don't know why everything in this test case is needed – additional connections, bogus ENABLE KEYS, the query from I_S – but I couldn't remove anything else.

      --connect (con1,localhost,root,,mysql)
      --connect (con2,localhost,root,,test)
       
      CREATE TABLE t1 (
        i int,
        f float,
        c1 char(255),
        c2 char(255),
        v varchar(64)
      );
       
      INSERT INTO t1 VALUES 
      (1, 1.0, REPEAT('a',255), REPEAT('x',255), NULL) ,  
      (2, 2.0, REPEAT('b',255), REPEAT('z',255), NULL) ;
      ALTER TABLE t1 ENABLE KEYS;
      SELECT COUNT(*) FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE;
      SELECT DISTINCT DEFAULT(i) FROM t1 GROUP BY @a := f WITH ROLLUP;
      

      10.2 8938031bc7eb78d406553465341338038cfb2e1a

      #3  <signal handler called>
      #4  __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:166
      #5  0x00007f6d6e50a257 in create_tmp_table (thd=<optimized out>, param=0x7f6d63c675d0, fields=..., group=group@entry=0x0, distinct=<optimized out>, distinct@entry=false, save_sum_fields=<optimized out>, save_sum_fields@entry=true, select_options=2147748609, rows_limit=18446744073709551615, table_alias=<optimized out>, do_not_open=true, keep_row_order=false) at /data/src/10.2/sql/sql_select.cc:16701
      #6  0x00007f6d6e5166e6 in JOIN::create_postjoin_aggr_table (this=this@entry=0x7f6d63c650c0, tab=tab@entry=0x7f6d63c66a90, table_fields=table_fields@entry=0x7f6d63c653e8, table_group=table_group@entry=0x0, save_sum_fields=save_sum_fields@entry=true, distinct=distinct@entry=false, keep_row_order=false) at /data/src/10.2/sql/sql_select.cc:2760
      #7  0x00007f6d6e517b7b in JOIN::make_aggr_tables_info (this=this@entry=0x7f6d63c650c0) at /data/src/10.2/sql/sql_select.cc:2447
      #8  0x00007f6d6e524c67 in JOIN::optimize_inner (this=this@entry=0x7f6d63c650c0) at /data/src/10.2/sql/sql_select.cc:2118
      #9  0x00007f6d6e52522f in JOIN::optimize (this=this@entry=0x7f6d63c650c0) at /data/src/10.2/sql/sql_select.cc:1076
      #10 0x00007f6d6e525bd5 in mysql_select (thd=thd@entry=0x7f6d63c16070, tables=0x7f6d63c643e0, wild_num=0, fields=..., conds=0x0, og_num=1, order=0x0, group=0x7f6d63c64f80, having=0x0, proc_param=0x0, select_options=2147748609, result=0x7f6d63c650a0, unit=0x7f6d63c19b48, select_lex=0x7f6d63c1a278) at /data/src/10.2/sql/sql_select.cc:3570
      #11 0x00007f6d6e525e8d in handle_select (thd=thd@entry=0x7f6d63c16070, lex=lex@entry=0x7f6d63c19a80, result=result@entry=0x7f6d63c650a0, setup_tables_done_option=setup_tables_done_option@entry=0) at /data/src/10.2/sql/sql_select.cc:373
      #12 0x00007f6d6e4b6849 in execute_sqlcom_select (thd=thd@entry=0x7f6d63c16070, all_tables=0x7f6d63c643e0) at /data/src/10.2/sql/sql_parse.cc:6347
      #13 0x00007f6d6e4bf6d2 in mysql_execute_command (thd=thd@entry=0x7f6d63c16070) at /data/src/10.2/sql/sql_parse.cc:3370
      #14 0x00007f6d6e4c92d2 in mysql_parse (thd=thd@entry=0x7f6d63c16070, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x7f6d6f4378e0, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /data/src/10.2/sql/sql_parse.cc:7790
      #15 0x00007f6d6e4cb55b in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x7f6d63c16070, packet=packet@entry=0x7f6d63c58071 "SELECT DISTINCT DEFAULT(i) FROM t1 GROUP BY @a := f WITH ROLLUP", packet_length=packet_length@entry=63, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /data/src/10.2/sql/sql_parse.cc:1799
      #16 0x00007f6d6e4ce08d in do_command (thd=0x7f6d63c16070) at /data/src/10.2/sql/sql_parse.cc:1359
      #17 0x00007f6d6e5bbf4a in do_handle_one_connection (connect=connect@entry=0x7f6d6b8716b0) at /data/src/10.2/sql/sql_connect.cc:1354
      #18 0x00007f6d6e5bc133 in handle_one_connection (arg=arg@entry=0x7f6d6b8716b0) at /data/src/10.2/sql/sql_connect.cc:1260
      #19 0x00007f6d6e86a07d in pfs_spawn_thread (arg=0x7f6d6b815df0) at /data/src/10.2/storage/perfschema/pfs.cc:1862
      #20 0x00007f6d6dbbd0a4 in start_thread (arg=0x7f6d6f439300) at pthread_create.c:309
      #21 0x00007f6d6c3dd87d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
      

      Attachments

        Issue Links

          Activity

            Can't reproduce it either on bb-10.2-monty 349d69e2e, nor on current 10.2 as of f2fe65106f; but the test case was so unreliable to begin with, that it's not surprising. We'll see if it re-appears.

            elenst Elena Stepanova added a comment - Can't reproduce it either on bb-10.2-monty 349d69e2e, nor on current 10.2 as of f2fe65106f; but the test case was so unreliable to begin with, that it's not surprising. We'll see if it re-appears.

            Not reproducible anymore, hopefully it's gone after numerous changes in the area. I see no point searching for a particular revision, since the test was unreliable.

            elenst Elena Stepanova added a comment - Not reproducible anymore, hopefully it's gone after numerous changes in the area. I see no point searching for a particular revision, since the test was unreliable.
            elenst Elena Stepanova added a comment - - edited

            Just got it on current 10.2.7 on Windows, in a concurrent test:

            Server version: 10.2.7-MariaDB-debug-log
            key_buffer_size=1048576
            read_buffer_size=131072
            max_used_connections=7
            max_threads=65537
            thread_count=12
            It is possible that mysqld could use up to 
            key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4199 K  bytes of memory
            Hope that's ok; if not, decrease some variables in the equation.
             
            Thread pointer: 0x493f9d1bb8
            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...
            mysqld.exe!create_tmp_table()[sql_select.cc:16565]
            mysqld.exe!JOIN::create_postjoin_aggr_table()[sql_select.cc:2832]
            mysqld.exe!JOIN::make_aggr_tables_info()[sql_select.cc:2517]
            mysqld.exe!JOIN::optimize_inner()[sql_select.cc:2159]
            mysqld.exe!JOIN::optimize()[sql_select.cc:1085]
            mysqld.exe!st_select_lex_unit::optimize()[sql_union.cc:906]
            mysqld.exe!st_select_lex_unit::exec()[sql_union.cc:940]
            mysqld.exe!mysql_union()[sql_union.cc:41]
            mysqld.exe!handle_select()[sql_select.cc:351]
            mysqld.exe!execute_sqlcom_select()[sql_parse.cc:6443]
            mysqld.exe!mysql_execute_command()[sql_parse.cc:3458]
            mysqld.exe!mysql_parse()[sql_parse.cc:7879]
            mysqld.exe!dispatch_command()[sql_parse.cc:1819]
            mysqld.exe!do_command()[sql_parse.cc:1361]
            mysqld.exe!threadpool_process_request()[threadpool_common.cc:346]
            mysqld.exe!tp_callback()[threadpool_common.cc:192]
            mysqld.exe!tp_callback()[threadpool_win.cc:378]
            mysqld.exe!work_callback()[threadpool_win.cc:452]
            ntdll.dll!RtlFreeUnicodeString()
            ntdll.dll!RtlFreeUnicodeString()
            KERNEL32.DLL!BaseThreadInitThunk()
            ntdll.dll!RtlUserThreadStart()
             
            Trying to get some variables.
            Some pointers may be invalid and cause the dump to abort.
            Query (0x494c3a2af0): /* GenTest::Transform::ExecuteAsUnion */ (  SELECT DISTINCT FOUND_ROWS() AS field1 FROM `dd` WHERE `col_datetime_key` HAVING BINARY -4642648265865560064 ORDER BY DES_ENCRYPT( 0, `col_varchar_nokey` ), BENCHMARK( 5, VAR_SAMP( `col_date_key` ) )  /* QNO 6261 CON_ID 16 */  ) UNION ALL (  SELECT DISTINCT FOUND_ROWS() AS field1 FROM `dd` WHERE `col_datetime_key` HAVING BINARY -4642648265865560064 ORDER BY DES_ENCRYPT( 0, `col_varchar_nokey` ), BENCHMARK( 5, VAR_SAMP( `col_date_key` ) )  /* QNO 6261 CON_ID 16 */  LIMIT 0 ) /* TRANSFORM_OUTCOME_UNORDERED_MATCH */ /* QNO 6287 CON_ID 16 */
            Connection ID (thread ID): 16
            Status: KILL_QUERY
            

            elenst Elena Stepanova added a comment - - edited Just got it on current 10.2.7 on Windows, in a concurrent test: Server version: 10.2.7-MariaDB-debug-log key_buffer_size=1048576 read_buffer_size=131072 max_used_connections=7 max_threads=65537 thread_count=12 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4199 K bytes of memory Hope that's ok; if not, decrease some variables in the equation.   Thread pointer: 0x493f9d1bb8 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... mysqld.exe!create_tmp_table()[sql_select.cc:16565] mysqld.exe!JOIN::create_postjoin_aggr_table()[sql_select.cc:2832] mysqld.exe!JOIN::make_aggr_tables_info()[sql_select.cc:2517] mysqld.exe!JOIN::optimize_inner()[sql_select.cc:2159] mysqld.exe!JOIN::optimize()[sql_select.cc:1085] mysqld.exe!st_select_lex_unit::optimize()[sql_union.cc:906] mysqld.exe!st_select_lex_unit::exec()[sql_union.cc:940] mysqld.exe!mysql_union()[sql_union.cc:41] mysqld.exe!handle_select()[sql_select.cc:351] mysqld.exe!execute_sqlcom_select()[sql_parse.cc:6443] mysqld.exe!mysql_execute_command()[sql_parse.cc:3458] mysqld.exe!mysql_parse()[sql_parse.cc:7879] mysqld.exe!dispatch_command()[sql_parse.cc:1819] mysqld.exe!do_command()[sql_parse.cc:1361] mysqld.exe!threadpool_process_request()[threadpool_common.cc:346] mysqld.exe!tp_callback()[threadpool_common.cc:192] mysqld.exe!tp_callback()[threadpool_win.cc:378] mysqld.exe!work_callback()[threadpool_win.cc:452] ntdll.dll!RtlFreeUnicodeString() ntdll.dll!RtlFreeUnicodeString() KERNEL32.DLL!BaseThreadInitThunk() ntdll.dll!RtlUserThreadStart()   Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x494c3a2af0): /* GenTest::Transform::ExecuteAsUnion */ ( SELECT DISTINCT FOUND_ROWS() AS field1 FROM `dd` WHERE `col_datetime_key` HAVING BINARY -4642648265865560064 ORDER BY DES_ENCRYPT( 0, `col_varchar_nokey` ), BENCHMARK( 5, VAR_SAMP( `col_date_key` ) ) /* QNO 6261 CON_ID 16 */ ) UNION ALL ( SELECT DISTINCT FOUND_ROWS() AS field1 FROM `dd` WHERE `col_datetime_key` HAVING BINARY -4642648265865560064 ORDER BY DES_ENCRYPT( 0, `col_varchar_nokey` ), BENCHMARK( 5, VAR_SAMP( `col_date_key` ) ) /* QNO 6261 CON_ID 16 */ LIMIT 0 ) /* TRANSFORM_OUTCOME_UNORDERED_MATCH */ /* QNO 6287 CON_ID 16 */ Connection ID (thread ID): 16 Status: KILL_QUERY

            This last occurrence is more related to MDEV-12575 though, and maybe it's different from the one described here. Closing again.

            elenst Elena Stepanova added a comment - This last occurrence is more related to MDEV-12575 though, and maybe it's different from the one described here. Closing again.

            People

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