Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2(EOL)
Description
PROCEDURE clause is not allowed in UNION. Previously, an attempt to use it caused a decent error ER_WRONG_USAGE. But now it causes either a syntax error on a release build, or an assertion failure on a debug build:
|
Stack trace from 10.2 025c4ec191e46719d3c51af6ee7a0ecc7a7dd335 |
mysqld: /data/src/10.2/sql/sql_parse.cc:7489: bool mysql_new_select(LEX*, bool): Assertion `lex->proc_list.elements == 0' failed.
|
160912 15:05:21 [ERROR] mysqld got signal 6 ;
|
...
|
#6 0x00007fb45cd4c266 in __assert_fail_base (fmt=0x7fb45ce85238 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7fb45ff1eadd "lex->proc_list.elements == 0", file=file@entry=0x7fb45ff1d658 "/data/src/10.2/sql/sql_parse.cc", line=line@entry=7489, function=function@entry=0x7fb45ff1fd00 <mysql_new_select(LEX*, bool)::__PRETTY_FUNCTION__> "bool mysql_new_select(LEX*, bool)") at assert.c:92
|
#7 0x00007fb45cd4c312 in __GI___assert_fail (assertion=0x7fb45ff1eadd "lex->proc_list.elements == 0", file=0x7fb45ff1d658 "/data/src/10.2/sql/sql_parse.cc", line=7489, function=0x7fb45ff1fd00 <mysql_new_select(LEX*, bool)::__PRETTY_FUNCTION__> "bool mysql_new_select(LEX*, bool)") at assert.c:101
|
#8 0x00007fb45f5dc347 in mysql_new_select (lex=0x7fb454019a50, move_down=false) at /data/src/10.2/sql/sql_parse.cc:7489
|
#9 0x00007fb45f7a7bed in add_select_to_union_list (lex=0x7fb454019a50, is_union_distinct=true, is_top_level=true) at /data/src/10.2/sql/sql_yacc.yy:707
|
#10 0x00007fb45f7d176b in MYSQLparse (thd=0x7fb454016070) at /data/src/10.2/sql/sql_yacc.yy:16092
|
#11 0x00007fb45f5e15f3 in parse_sql (thd=0x7fb454016070, parser_state=0x7fb46052cdd0, creation_ctx=0x0, do_pfs_digest=true) at /data/src/10.2/sql/sql_parse.cc:9793
|
#12 0x00007fb45f5dcfd7 in mysql_parse (thd=0x7fb454016070, rawbuf=0x7fb454064088 "( SELECT * FROM t1 PROCEDURE ANALYSE( 10, 10 ) ) \nUNION\n( SELECT * FROM t1 PROCEDURE ANALYSE( 10, 10 ) )", length=104, parser_state=0x7fb46052cdd0, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7727
|
#13 0x00007fb45f5cb555 in dispatch_command (command=COM_QUERY, thd=0x7fb454016070, packet=0x7fb454058071 "( SELECT * FROM t1 PROCEDURE ANALYSE( 10, 10 ) ) \nUNION\n( SELECT * FROM t1 PROCEDURE ANALYSE( 10, 10 ) )", packet_length=104, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1805
|
#14 0x00007fb45f5c9f86 in do_command (thd=0x7fb454016070) at /data/src/10.2/sql/sql_parse.cc:1365
|
#15 0x00007fb45f705912 in do_handle_one_connection (connect=0x7fb45c46d410) at /data/src/10.2/sql/sql_connect.cc:1354
|
#16 0x00007fb45f70569f in handle_one_connection (arg=0x7fb45c46d410) at /data/src/10.2/sql/sql_connect.cc:1260
|
#17 0x00007fb45fa13ea4 in pfs_spawn_thread (arg=0x7fb45c4519f0) at /data/src/10.2/storage/perfschema/pfs.cc:1862
|
#18 0x00007fb45ec4e0a4 in start_thread (arg=0x7fb46052e300) at pthread_create.c:309
|
#19 0x00007fb45ce0687d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
|
|
Test case |
CREATE TABLE t1 (i INT); |
|
|
--error ER_WRONG_USAGE
|
( SELECT * FROM t1 PROCEDURE ANALYSE( 10, 10 ) ) |
UNION
|
( SELECT * FROM t1 PROCEDURE ANALYSE( 10, 10 ) ); |
It started happening after recent merges.
Attachments
Activity
| Field | Original Value | New Value |
|---|---|---|
| Attachment | mdev10779-2.yy [ 42517 ] |
| Assignee | Elena Stepanova [ elenst ] | Oleksandr Byelkin [ sanja ] |
| Description |
http://buildbot.askmonty.org/buildbot/builders/win-rqg-se/builds/2677/steps/rqg_crash_tests/logs/stdio
{noformat} Assertion failed: lex->proc_list.elements == 0, file E:\buildbot\bbwin1\win-rqg-se\build-debug\sql\sql_parse.cc, line 7473 R6010 - abort() has been called 160907 15:27:57 [ERROR] mysqld got exception 0x80000003 ; 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.2.2-MariaDB-debug-log key_buffer_size=1048576 read_buffer_size=131072 max_used_connections=8 max_threads=1001 thread_count=6 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 388178 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0xb1ee29fc88 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!my_sigabrt_handler()[my_thr_init.c:477] mysqld.exe!raise()[winsig.c:594] mysqld.exe!abort()[abort.c:82] mysqld.exe!_wassert()[assert.c:380] mysqld.exe!mysql_new_select()[sql_parse.cc:7473] mysqld.exe!add_select_to_union_list()[sql_yacc.yy:707] mysqld.exe!MYSQLparse()[sql_yacc.yy:16071] mysqld.exe!parse_sql()[sql_parse.cc:9778] mysqld.exe!mysql_parse()[sql_parse.cc:7711] mysqld.exe!dispatch_command()[sql_parse.cc:1796] mysqld.exe!do_command()[sql_parse.cc:1353] mysqld.exe!threadpool_process_request()[threadpool_common.cc:252] mysqld.exe!io_completion_callback()[threadpool_win.cc:462] KERNEL32.DLL!VirtualUnlock() ntdll.dll!RtlGetActiveActivationContext() 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 (0xb1ee005780): /* GenTest::Transform::ExecuteAsUnion */ ( SELECT pk,col_float,pk FROM testdb_N.t1_temp3_N AS A NATURAL JOIN testdb_S.t1_temp2_N B WHERE `pk` BETWEEN 1 AND 3 + 1 PROCEDURE ANALYSE( 10, 2000 ) /* QUERY_NO 6147 CON_ID 10 */ ) UNION ALL ( SELECT pk,col_float,pk FROM testdb_N.t1_temp3_N AS A NATURAL JOIN testdb_S.t1_temp2_N B WHERE `pk` BETWEEN 1 AND 3 + 1 PROCEDURE ANALYSE( 10, 2000 ) /* QUERY_NO 6147 CON_ID 10 */ LIMIT 0 ) /* TRANSFORM_OUTCOME_UNORDERED_MATCH */ /* QUERY_NO 6162 CON_ID 10 */ Connection ID (thread ID): 190 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=off {noformat} |
PROCEDURE clause is not allowed in UNION. Previously, an attempt to use it caused a decent error ER_WRONG_USAGE. But now it causes either a syntax error on a release build, or an assertion failure on a debug build:
{noformat:title=Stack trace from 10.2 025c4ec191e46719d3c51af6ee7a0ecc7a7dd335} mysqld: /data/src/10.2/sql/sql_parse.cc:7489: bool mysql_new_select(LEX*, bool): Assertion `lex->proc_list.elements == 0' failed. 160912 15:05:21 [ERROR] mysqld got signal 6 ; ... #6 0x00007fb45cd4c266 in __assert_fail_base (fmt=0x7fb45ce85238 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7fb45ff1eadd "lex->proc_list.elements == 0", file=file@entry=0x7fb45ff1d658 "/data/src/10.2/sql/sql_parse.cc", line=line@entry=7489, function=function@entry=0x7fb45ff1fd00 <mysql_new_select(LEX*, bool)::__PRETTY_FUNCTION__> "bool mysql_new_select(LEX*, bool)") at assert.c:92 #7 0x00007fb45cd4c312 in __GI___assert_fail (assertion=0x7fb45ff1eadd "lex->proc_list.elements == 0", file=0x7fb45ff1d658 "/data/src/10.2/sql/sql_parse.cc", line=7489, function=0x7fb45ff1fd00 <mysql_new_select(LEX*, bool)::__PRETTY_FUNCTION__> "bool mysql_new_select(LEX*, bool)") at assert.c:101 #8 0x00007fb45f5dc347 in mysql_new_select (lex=0x7fb454019a50, move_down=false) at /data/src/10.2/sql/sql_parse.cc:7489 #9 0x00007fb45f7a7bed in add_select_to_union_list (lex=0x7fb454019a50, is_union_distinct=true, is_top_level=true) at /data/src/10.2/sql/sql_yacc.yy:707 #10 0x00007fb45f7d176b in MYSQLparse (thd=0x7fb454016070) at /data/src/10.2/sql/sql_yacc.yy:16092 #11 0x00007fb45f5e15f3 in parse_sql (thd=0x7fb454016070, parser_state=0x7fb46052cdd0, creation_ctx=0x0, do_pfs_digest=true) at /data/src/10.2/sql/sql_parse.cc:9793 #12 0x00007fb45f5dcfd7 in mysql_parse (thd=0x7fb454016070, rawbuf=0x7fb454064088 "( SELECT * FROM t1 PROCEDURE ANALYSE( 10, 10 ) ) \nUNION\n( SELECT * FROM t1 PROCEDURE ANALYSE( 10, 10 ) )", length=104, parser_state=0x7fb46052cdd0, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7727 #13 0x00007fb45f5cb555 in dispatch_command (command=COM_QUERY, thd=0x7fb454016070, packet=0x7fb454058071 "( SELECT * FROM t1 PROCEDURE ANALYSE( 10, 10 ) ) \nUNION\n( SELECT * FROM t1 PROCEDURE ANALYSE( 10, 10 ) )", packet_length=104, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1805 #14 0x00007fb45f5c9f86 in do_command (thd=0x7fb454016070) at /data/src/10.2/sql/sql_parse.cc:1365 #15 0x00007fb45f705912 in do_handle_one_connection (connect=0x7fb45c46d410) at /data/src/10.2/sql/sql_connect.cc:1354 #16 0x00007fb45f70569f in handle_one_connection (arg=0x7fb45c46d410) at /data/src/10.2/sql/sql_connect.cc:1260 #17 0x00007fb45fa13ea4 in pfs_spawn_thread (arg=0x7fb45c4519f0) at /data/src/10.2/storage/perfschema/pfs.cc:1862 #18 0x00007fb45ec4e0a4 in start_thread (arg=0x7fb46052e300) at pthread_create.c:309 #19 0x00007fb45ce0687d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 {noformat} {code:sql|title=Test case} CREATE TABLE t1 (i INT); --error ER_WRONG_USAGE ( SELECT * FROM t1 PROCEDURE ANALYSE( 10, 10 ) ) UNION ( SELECT * FROM t1 PROCEDURE ANALYSE( 10, 10 ) ); {code} It started happening after recent merges. |
| Summary | [Draft] Assertion failed: lex->proc_list.elements == 0 | Failing assertion lex->proc_list.elements == 0 or syntax error on PROCEDURE ANALYSE in UNION |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Labels | regression-10.2 |
The problem is that before mysql_new_select() reported this error.
Now it replaced with DBUG_ASSERT by this patch:
commit dd283db6bc4ecbb18127a8b10d49073047ea990b
Author: Alexander Barkov <bar@mariadb.org> Wed Sep 7 09:36:22 2016
Committer: Alexander Barkov <bar@mariadb.org> Wed Sep 7 09:36:22 2016
MDEV-8909 union parser cleanup
This is the final patch removing some old remainders that are
not needed anymore.
So probably author of the patch knowing more how to fix.
| Assignee | Oleksandr Byelkin [ sanja ] | Alexander Barkov [ bar ] |
| Component/s | Parser [ 10201 ] | |
| Fix Version/s | 10.2.2 [ 22013 ] | |
| Fix Version/s | 10.2 [ 14601 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | In Progress [ 3 ] | Closed [ 6 ] |
| Workflow | MariaDB v3 [ 77019 ] | MariaDB v4 [ 150896 ] |
perl ./runall-new.pl --no-mask --seed=1473250770 --threads=2 --duration=900 --queries=100M --reporters=QueryTimeout,Backtrace,ErrorLog,Deadlock,Shutdown --redefine=conf/mariadb/redefine_random_keys.yy --validators=TransformerNoComparator --transformers=ExecuteAsUnion --grammar=mdev10779-2.yy --gendata=conf/runtime/concurrency_1.zz --mtr-build-thread=300 --basedir1=/data/bld/10.2 --vardir1=/data/logs/analyze5bmdev10779-2.yy
RQG 22d8d863bab (experimental branch)