[MDEV-11590] Server crashes in create_tmp_table / JOIN::create_postjoin_aggr_table Created: 2016-12-17  Updated: 2021-08-25  Resolved: 2017-07-10

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.2
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Elena Stepanova
Resolution: Cannot Reproduce Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-5800 indexes on virtual (not materialized)... Closed
relates to MDEV-12575 Server crash in AGGR_OP::put_record o... Closed
relates to MDEV-26423 MariaDB server crash in Create_tmp_ta... Closed

 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



 Comments   
Comment by Elena Stepanova [ 2017-01-02 ]

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.

Comment by Elena Stepanova [ 2017-06-21 ]

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.

Comment by Elena Stepanova [ 2017-07-10 ]

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

Comment by Elena Stepanova [ 2017-07-10 ]

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

Generated at Thu Feb 08 07:51:07 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.