[MDEV-19352] Server crash in alloc_histograms_for_table_share upon query from information schema Created: 2019-04-28  Updated: 2019-05-08  Resolved: 2019-05-01

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.1, 10.2, 10.3, 10.4
Fix Version/s: 10.2.24, 10.1.41, 10.3.15, 10.4.5

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Varun Gupta (Inactive)
Resolution: Fixed Votes: 0
Labels: None


 Description    

CREATE TABLE t1 (a INT);
 
CREATE TABLE t2 (b INT);
 
CREATE VIEW v AS SELECT * FROM t1 JOIN t2;
 
--error ER_NO_SUCH_TABLE
 
INSERT INTO t1 SELECT * FROM x;
 
SELECT * FROM information_schema.tables;
 
 
 
# Cleanup
 
DROP VIEW v;
 
DROP TABLE t1, t2;

10.4 81f6a3b0

 
#3  <signal handler called>
 
#4  0x000056230487eecc in alloc_histograms_for_table_share (thd=0x7f1744000b00, table_share=0x7f174414c508, is_safe=false) at /data/src/10.4/sql/sql_statistics.cc:2446
 
#5  0x0000562304880a36 in read_histograms_for_table (thd=0x7f1744000b00, table=0x7f174414eae0, stat_tables=0x7f17540604e0) at /data/src/10.4/sql/sql_statistics.cc:3292
 
#6  0x0000562304880e8a in read_statistics_for_tables_if_needed (thd=0x7f1744000b00, tables=0x7f1744043c38) at /data/src/10.4/sql/sql_statistics.cc:3374
 
#7  0x0000562304865694 in fill_schema_table_by_open (thd=0x7f1744000b00, mem_root=0x7f1754063680, is_show_fields_or_keys=false, table=0x7f1744157e18, schema_table=0x562305e48080 <schema_tables+2048>, orig_db_name=0x7f1744133408, orig_table_name=0x7f1744133460, open_tables_state_backup=0x7f17540636d0, can_deadlock=false) at /data/src/10.4/sql/sql_show.cc:4645
 
#8  0x0000562304866fa9 in get_all_tables (thd=0x7f1744000b00, tables=0x7f1744015c60, cond=0x0) at /data/src/10.4/sql/sql_show.cc:5284
 
#9  0x000056230487803b in get_schema_tables_result (join=0x7f17440186c8, executed_place=PROCESSED_BY_JOIN_EXEC) at /data/src/10.4/sql/sql_show.cc:8878
 
#10 0x000056230480cf98 in JOIN::exec_inner (this=0x7f17440186c8) at /data/src/10.4/sql/sql_select.cc:4346
 
#11 0x000056230480c41e in JOIN::exec (this=0x7f17440186c8) at /data/src/10.4/sql/sql_select.cc:4171
 
#12 0x000056230480dad0 in mysql_select (thd=0x7f1744000b00, tables=0x7f1744015c60, wild_num=1, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2684619520, result=0x7f17440186a0, unit=0x7f1744004a28, select_lex=0x7f1744015688) at /data/src/10.4/sql/sql_select.cc:4603
 
#13 0x00005623047fe040 in handle_select (thd=0x7f1744000b00, lex=0x7f1744004960, result=0x7f17440186a0, setup_tables_done_option=0) at /data/src/10.4/sql/sql_select.cc:424
 
#14 0x00005623047c78d9 in execute_sqlcom_select (thd=0x7f1744000b00, all_tables=0x7f1744015c60) at /data/src/10.4/sql/sql_parse.cc:6597
 
#15 0x00005623047bceaf in mysql_execute_command (thd=0x7f1744000b00) at /data/src/10.4/sql/sql_parse.cc:3886
 
#16 0x00005623047cb65f in mysql_parse (thd=0x7f1744000b00, rawbuf=0x7f17440155d8 "SELECT * FROM information_schema.tables", length=39, parser_state=0x7f1754065180, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:8149
 
#17 0x00005623047b70b6 in dispatch_command (command=COM_QUERY, thd=0x7f1744000b00, packet=0x7f17441398f1 "SELECT * FROM information_schema.tables", packet_length=39, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1828
 
#18 0x00005623047b589c in do_command (thd=0x7f1744000b00) at /data/src/10.4/sql/sql_parse.cc:1361
 
#19 0x000056230492dcad in do_handle_one_connection (connect=0x562307a58530) at /data/src/10.4/sql/sql_connect.cc:1398
 
#20 0x000056230492da1e in handle_one_connection (arg=0x562307a58530) at /data/src/10.4/sql/sql_connect.cc:1301
 
#21 0x0000562304d52d9d in pfs_spawn_thread (arg=0x562307b5c060) at /data/src/10.4/storage/perfschema/pfs.cc:1862
 
#22 0x00007f175bf86494 in start_thread (arg=0x7f1754066700) at pthread_create.c:333
 
#23 0x00007f1759f4e93f in clone () from /lib/x86_64-linux-gnu/libc.so.6

All of debug, ASAN and non-debug builds are affected.

The problem appeared in 10.4 after this merge:

commit e6bdf77e4be48750c4808a09af197ed91fd69a61
 
Merge: 1599825 acf6f92
 
Author: Marko Mäkelä
 
Date:   Thu Apr 25 16:05:20 2019 +0300
 
 
 
    Merge 10.3 into 10.4
 
    
    In is_eits_usable(), we disable an assertion that fails due to
 
    MDEV-19334.

Note: Even though the problem appeared after the merge above, I can't reproduce it on 10.3 even with all 10.4-specific optimizer options I can think of:

perl ./mtr bug.2230 --mysqld=--optimizer-use-condition-selectivity=4 --mysqld=--use-stat-tables=PREFERABLY --mysqld=--histogram-size=254 --mysqld=--histogram-type=DOUBLE_PREC_HB
 
 
 
...
 
bug.2230                                 [ pass ]    114
 
--------------------------------------------------------------------------
 
The servers were restarted 0 times
 
Spent 0.114 of 9 seconds executing testcases
 
 
 
Completed: All 1 tests were successful.



 Comments   
Comment by Varun Gupta (Inactive) [ 2019-04-29 ]

After Igor's fix for MDEV-19351 , this is reproducible on 10.3 even.

This case should be reproducible on all versions starting from 10.1 . Looks like this would also solve the issue of MDEV-19079

Comment by Varun Gupta (Inactive) [ 2019-04-29 ]

A small patch needs to be applied, we need to set the correct sql_command, aligning this with higher versions, sort of a side effect of MDEV-17605

diff --git a/sql/sql_show.cc b/sql/sql_show.cc
 
index 7f0c50a2e55..d8b35eda089 100644
 
--- a/sql/sql_show.cc
 
+++ b/sql/sql_show.cc
 
@@ -4272,8 +4272,8 @@ fill_schema_table_by_open(THD *thd, bool is_show_fields_or_keys,
 
     SQLCOM_SHOW_FIELDS is used because it satisfies
 
     'only_view_structure()'.
 
   */
 
-  lex->sql_command= SQLCOM_SHOW_FIELDS;
 
   thd->force_read_stats= get_schema_table_idx(schema_table) == SCH_STATISTICS;
 
+  lex->sql_command= SQLCOM_SHOW_FIELDS;
 
   result= (open_temporary_tables(thd, table_list) ||
 
            open_normal_and_derived_tables(thd, table_list,
 
                                           (MYSQL_OPEN_IGNORE_FLUSH |
 
@@ -4281,16 +4281,15 @@ fill_schema_table_by_open(THD *thd, bool is_show_fields_or_keys,
 
                                            (can_deadlock ?
 
                                             MYSQL_OPEN_FAIL_ON_MDL_CONFLICT : 0)),
 
                                           DT_PREPARE | DT_CREATE));
 
-
 
-  (void) read_statistics_for_tables_if_needed(thd, table_list);
 
-  thd->force_read_stats= false;
 
-

For all versions the test case that fails after applying the above patch (needed for 10.1 and 10.2)

--source include/have_innodb.inc
 
set use_stat_tables='preferably';
 
set optimizer_use_condition_selectivity=4;
 
set histogram_size=255;
 
 
 
 
 
CREATE TABLE t1 (a INT);
 
 
 
CREATE TABLE t2 (b INT);
 
CREATE VIEW v AS SELECT * FROM t1 JOIN t2;
 
--error ER_NO_SUCH_TABLE
 
INSERT INTO t1 SELECT * FROM x;
 
SELECT * FROM information_schema.tables where TABLE_NAME in ('v');
 
 
 
# Cleanup
 
DROP VIEW v;
 
DROP TABLE t1, t2

What we needed for in the test case was that for one table we have allocated statistics (that is table t1 in this case, with insert we allocate statistics to the TABLE_SHARE object)

For table t2 we don't allocate statistics, as no statement(no insert) that calls alloc_statistics_for_table_share()

Comment by Varun Gupta (Inactive) [ 2019-04-29 ]

Patch
http://lists.askmonty.org/pipermail/commits/2019-April/013711.html

Comment by Varun Gupta (Inactive) [ 2019-04-30 ]

Updated Patch as @igor requested

http://lists.askmonty.org/pipermail/commits/2019-April/013715.html

Comment by Igor Babaev [ 2019-05-01 ]

Ok to push into 10.1

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