[MDEV-19238] Mariadb spider - crashes on where null Created: 2019-04-11  Updated: 2019-10-09  Resolved: 2019-10-05

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.3.13
Fix Version/s: 10.3.19, 10.4.9

Type: Bug Priority: Major
Reporter: Zacharya Assignee: Oleksandr Byelkin
Resolution: Fixed Votes: 0
Labels: None
Environment:

Ubuntu 18.04, maraidb:10.3 docker image



 Description   

When running a query on spider table with "WHERE NULL" (or for example where JSON function that returns NULL) Mariadb crashes.
Simple reproduce:

FROM mariadb:10.3
 
RUN apt update && apt install -y mariadb-plugin-spider
RUN cp /usr/share/mysql/install_spider.sql /docker-entrypoint-initdb.d/

Launching docker with "mariadb:10.3" and running the next queries:

CREATE DATABASE test;
USE test;
 
CREATE TABLE `test` (
    id INT
);

Launching a docker with the dockerfile above and running the next queries:

CREATE DATABASE test;
CREATE SERVER node1 FOREIGN DATA WRAPPER mysql OPTIONS(HOST "node1", USER "root", PORT 3306, DATABASE "test");
 
USE test;
CREATE TABLE `test` ENGINE=SPIDER COMMENT='wrapper "mysql", srv "node1", table "test"';
SELECT * FROM test WHERE NULL;

The last query will cause mariadb to crash with the next message:

190411 11:59:28 [ERROR] mysqld got signal 11 ;
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.3.13-MariaDB-1:10.3.13+maria~bionic
key_buffer_size=134217728
read_buffer_size=2097152
max_used_connections=1
max_threads=102
thread_count=27
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 760012 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x7fe608000c08
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 = 0x7fe6d023ddd8 thread_stack 0x49000
mysqld(my_print_stacktrace+0x2e)[0x55cf8e4ee47e]
mysqld(handle_fatal_signal+0x5a5)[0x55cf8df8e295]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7fe6e5691890]
mysqld(_ZN4JOIN21make_aggr_tables_infoEv+0x8b5)[0x55cf8ddfd235]
mysqld(_ZN4JOIN15optimize_stage2Ev+0xc4)[0x55cf8de03744]
mysqld(_ZN4JOIN14optimize_innerEv+0xe69)[0x55cf8de06889]
mysqld(_ZN4JOIN8optimizeEv+0x37)[0x55cf8de082f7]
mysqld(_Z12mysql_selectP3THDP10TABLE_LISTjR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x856)[0x55cf8de0a126]
mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x14d)[0x55cf8de0a32d]
mysqld(+0x564661)[0x55cf8ddab661]
mysqld(_Z21mysql_execute_commandP3THD+0x5ec2)[0x55cf8ddb7e82]
mysqld(_Z11mysql_parseP3THDPcjP12Parser_statebb+0x20a)[0x55cf8ddbaa4a]
mysqld(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0x1cc7)[0x55cf8ddbd447]
mysqld(_Z10do_commandP3THD+0x178)[0x55cf8ddbe1e8]
mysqld(_Z24do_handle_one_connectionP7CONNECT+0x212)[0x55cf8de8dd92]
mysqld(handle_one_connection+0x3d)[0x55cf8de8df6d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76db)[0x7fe6e56866db]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fe6e4c8888f]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7fe608011bc0): select * from test where null
Connection ID (thread ID): 31
Status: NOT_KILLED
 
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on
 
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.



 Comments   
Comment by Kentoku Shiba (Inactive) [ 2019-04-17 ]

It looks it shouldn't call handlerton->create_group_by() if join_tab is null.
Please review the following commit.
5dc4d9b

Comment by Oleksandr Byelkin [ 2019-10-04 ]

it looks like I have just fixed duplicate https://jira.mariadb.org/browse/MDEV-20753

The problem is that optimiser resolved query without the tables (in your case it is NULL where clause in my it is LIMIT 0).
I got review from optimiser team already on my fix, it is better to check absence of tables, then consequences (NULL reference)).

I can add your test suites and push all together if you are not against.

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