Bug #78188 handle_fatal_signal (sig=11) in free_root from test_quick_select
| Submitted: | 24 Aug 2015 11:33 | Modified: | 5 Oct 2015 2:16 |
|---|---|---|---|
| Reporter: | Roel Van de Paar | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Optimizer | Severity: | S1 (Critical) |
| Version: | 5.7.8 (RC2), 5.7.9 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | opt | ||
[24 Aug 2015 11:33]
Roel Van de Paar
[24 Aug 2015 12:11]
MySQL Verification Team
Hello Roel, Thank you for the report and test case. Observed that 5.7.9 daily build is affected. Thanks, Umesh
[24 Aug 2015 12:11]
MySQL Verification Team
// Start up and build details
bin/mysql_install_db --insecure --basedir=/export/umesh/server/binaries/mysql-advanced-5.7.9-linux-x86_64 --datadir=/export/umesh/server/binaries/mysql-advanced-5.7.9-linux-x86_64/78188 -v
bin/mysqld --no-defaults --basedir=/export/umesh/server/binaries/mysql-advanced-5.7.9-linux-x86_64 --datadir=/export/umesh/server/binaries/mysql-advanced-5.7.9-linux-x86_64/78188 --core-file --socket=/tmp/mysql_ushastry.sock --port=15000 --log-error=/export/umesh/server/binaries/mysql-advanced-5.7.9-linux-x86_64/78188/log.err --range-alloc-block-size=1125899906842624 2>&1 &
[umshastr@hod03]/export/umesh/server/binaries/mysql-advanced-5.7.9-linux-x86_64: cat docs/INFO_SRC
commit: 307bfadb48a0c52a5113f6b63dcb9716f38cdc61
date: 2015-08-23 17:02:36 +0800
build-date: 2015-08-23 18:02:59 +0200
short: 307bfad
branch: mysql-5.7
MySQL source 5.7.9
(gdb) bt
#0 0x00007fd82b5ee771 in pthread_kill () from /lib64/libpthread.so.0
#1 0x000000000079eed5 in handle_fatal_signal (sig=11) at /export/home2/pb2/build/sb_0-16239026-1440346605.96/mysqlcom-pro-5.7.9/sql/signal_handler.cc:220
#2 <signal handler called>
#3 get_full_func_mm_tree (param=0x7fd7fe153cd0, predicand=0x7fd7b401c008, op=0x7fd7b401c128, value=0x7fd7b4006b90, inv=false)
at /export/home2/pb2/build/sb_0-16239026-1440346605.96/mysqlcom-pro-5.7.9/sql/opt_range.cc:6472
#4 0x0000000000d835da in get_mm_tree (param=0x7fd7fe153cd0, cond=0x7fd7b401c128) at /export/home2/pb2/build/sb_0-16239026-1440346605.96/mysqlcom-pro-5.7.9/sql/opt_range.cc:6740
#5 0x0000000000d83145 in get_mm_tree (param=0x7fd7fe153cd0, cond=0x7fd7b4006988) at /export/home2/pb2/build/sb_0-16239026-1440346605.96/mysqlcom-pro-5.7.9/sql/opt_range.cc:6553
#6 0x0000000000d8bf81 in test_quick_select (thd=thd@entry=0x7fd7b4000b50, keys_to_use=..., prev_tables=prev_tables@entry=0, limit=limit@entry=18446744073709551615,
force_quick_range=force_quick_range@entry=false, interesting_order=interesting_order@entry=st_order::ORDER_NOT_RELEVANT, tab=tab@entry=0x7fd7b401ccd8, cond=0x7fd7b4006988,
needed_reg=needed_reg@entry=0x7fd7b401cd18, quick=quick@entry=0x7fd7fe155f80) at /export/home2/pb2/build/sb_0-16239026-1440346605.96/mysqlcom-pro-5.7.9/sql/opt_range.cc:2932
#7 0x0000000000c46b55 in get_quick_record_count (limit=18446744073709551615, tab=0x7fd7b401ccd8, thd=0x7fd7b4000b50)
at /export/home2/pb2/build/sb_0-16239026-1440346605.96/mysqlcom-pro-5.7.9/sql/sql_optimizer.cc:5750
#8 JOIN::estimate_rowcount (this=this@entry=0x7fd7b401c8f0) at /export/home2/pb2/build/sb_0-16239026-1440346605.96/mysqlcom-pro-5.7.9/sql/sql_optimizer.cc:5497
#9 0x0000000000c4cc67 in JOIN::make_join_plan (this=this@entry=0x7fd7b401c8f0) at /export/home2/pb2/build/sb_0-16239026-1440346605.96/mysqlcom-pro-5.7.9/sql/sql_optimizer.cc:4854
#10 0x0000000000c4e47b in JOIN::optimize (this=0x7fd7b401c8f0) at /export/home2/pb2/build/sb_0-16239026-1440346605.96/mysqlcom-pro-5.7.9/sql/sql_optimizer.cc:354
#11 0x0000000000c91445 in st_select_lex::optimize (this=this@entry=0x7fd7b40054a0, thd=thd@entry=0x7fd7b4000b50)
at /export/home2/pb2/build/sb_0-16239026-1440346605.96/mysqlcom-pro-5.7.9/sql/sql_select.cc:1008
#12 0x0000000000c91625 in handle_query (thd=thd@entry=0x7fd7b4000b50, lex=lex@entry=0x7fd7b4002c00, result=result@entry=0x7fd7b401c370, added_options=added_options@entry=0,
removed_options=removed_options@entry=0) at /export/home2/pb2/build/sb_0-16239026-1440346605.96/mysqlcom-pro-5.7.9/sql/sql_select.cc:164
#13 0x0000000000762006 in execute_sqlcom_select (thd=thd@entry=0x7fd7b4000b50, all_tables=<optimized out>)
at /export/home2/pb2/build/sb_0-16239026-1440346605.96/mysqlcom-pro-5.7.9/sql/sql_parse.cc:4941
#14 0x0000000000c56cd6 in mysql_execute_command (thd=thd@entry=0x7fd7b4000b50, first_level=first_level@entry=true)
at /export/home2/pb2/build/sb_0-16239026-1440346605.96/mysqlcom-pro-5.7.9/sql/sql_parse.cc:2597
#15 0x0000000000c5a5d5 in mysql_parse (thd=thd@entry=0x7fd7b4000b50, parser_state=parser_state@entry=0x7fd7fe1577b0)
at /export/home2/pb2/build/sb_0-16239026-1440346605.96/mysqlcom-pro-5.7.9/sql/sql_parse.cc:5353
#16 0x0000000000c5af7a in dispatch_command (thd=thd@entry=0x7fd7b4000b50, com_data=com_data@entry=0x7fd7fe157e00, command=COM_QUERY)
at /export/home2/pb2/build/sb_0-16239026-1440346605.96/mysqlcom-pro-5.7.9/sql/sql_parse.cc:1284
#17 0x0000000000c5c7ef in do_command (thd=thd@entry=0x7fd7b4000b50) at /export/home2/pb2/build/sb_0-16239026-1440346605.96/mysqlcom-pro-5.7.9/sql/sql_parse.cc:852
#18 0x0000000000d12740 in handle_connection (arg=arg@entry=0x2f24c20)
at /export/home2/pb2/build/sb_0-16239026-1440346605.96/mysqlcom-pro-5.7.9/sql/conn_handler/connection_handler_per_thread.cc:300
#19 0x00000000011a8510 in pfs_spawn_thread (arg=0x320a210) at /export/home2/pb2/build/sb_0-16239026-1440346605.96/mysqlcom-pro-5.7.9/storage/perfschema/pfs.cc:2191
#20 0x00007fd82b5e9df3 in start_thread () from /lib64/libpthread.so.0
#21 0x00007fd82a0aa47d in clone () from /lib64/libc.so.6
(gdb)
[28 Aug 2015 10:33]
MySQL Verification Team
Just to confirm I've verified on release builds of 5.7.8, 5.7.9
[2 Oct 2015 0:36]
Paul DuBois
Noted in 5.7.9, 5.8.0 changelogs. Subqueries that used a derived table and contained a set function referring to a column from that derived table might be aggregated in the wrong query block.
[2 Oct 2015 15:54]
Paul DuBois
Ignore previous comment; it was intended for a different bug.
[2 Oct 2015 16:07]
Paul DuBois
Noted in 5.7.9, 5.8.0 changelogs. On non-Windows systems, setting range_alloc_block_size or query_alloc_block_size to a value larger than 32 bits at startup could cause a server exit. The maximum value for these system variables (on all platforms) is now limited to 2^32 - 1, rounded down to the nearest multiple of 1024.
[5 Oct 2015 2:16]
Roel Van de Paar
Another crash # mysqld options required for replay: --range-alloc-block-size=1125899906842624 DROP DATABASE test;CREATE DATABASE test;USE test; delete from mysql.columns_priv where user='_1';
Portions of this website are copyright © 2001, 2002 The PHP Group
Page generated in 0.044 sec. using MySQL 8.4.7-u6-cloud
Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the
respective copyright holders.
It is not reviewed in advance
by Oracle and does not necessarily represent the opinion of
Oracle or any other party.