[MDEV-8087] Server crashed in Time_and_counter_tracker::incr_loops - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Fixed
Affects Version/s: 10.1(EOL)
Fix Version/s: 10.1.8
Component/s: Parser
Labels:
None

Sprint:
10.1.7-1, 10.1.8-1, 10.1.8-3, 10.1.8-4

Description

Note: unfortunately, I only have a concurrent test case. Run it with --repeat=N.

CREATE PROCEDURE proc() SELECT * FROM v2;

--connect (con1,localhost,root,,test)

CREATE ALGORITHM = UNDEFINED VIEW v1 AS SELECT 1;

CREATE ALGORITHM = TEMPTABLE VIEW v2 AS SELECT 3 FROM v1;

DROP VIEW v1;

--error ER_VIEW_INVALID

CALL proc();

--connection default

--send CREATE ALGORITHM = TEMPTABLE VIEW v1 AS SELECT 2

--connection con1

CALL proc();

Stack trace from 1a3321b6496dcdbac47efb48e7b66aa23fd8e0f7
#3 <signal handler called>
#4 0x00007fb8fc286e44 in Time_and_counter_tracker::incr_loops (this=0x68) at 10.1/sql/sql_analyze_stmt.h:89
#5 0x00007fb8fc3024c5 in JOIN::exec (this=0x7fb8f0c8bec0) at 10.1/sql/sql_select.cc:2391
#6 0x00007fb8fc305b03 in mysql_select (thd=0x7fb8f2ab2070, rref_pointer_array=0x7fb8f0c833c8, tables=0x7fb8f0c8e088, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2416185088, result=0x7fb8f0c8bdc8, unit=0x7fb8f0c82a60, select_lex=0x7fb8f0c83150) at 10.1/sql/sql_select.cc:3323
#7 0x00007fb8fc289302 in mysql_derived_fill (thd=0x7fb8f2ab2070, lex=0x7fb8f0c7bb68, derived=0x7fb8f0c82188) at 10.1/sql/sql_derived.cc:938
#8 0x00007fb8fc288e94 in mysql_derived_optimize (thd=0x7fb8f2ab2070, lex=0x7fb8f0c7bb68, derived=0x7fb8f0c82188) at 10.1/sql/sql_derived.cc:827
#9 0x00007fb8fc287bd7 in mysql_handle_single_derived (lex=0x7fb8f0c7bb68, derived=0x7fb8f0c82188, phases=4) at 10.1/sql/sql_derived.cc:195
#10 0x00007fb8fc3b6620 in TABLE_LIST::handle_derived (this=0x7fb8f0c82188, lex=0x7fb8f0c7bb68, phases=4) at 10.1/sql/table.cc:7090
#11 0x00007fb8fc2a5008 in st_select_lex::handle_derived (this=0x7fb8f0c7c320, lex=0x7fb8f0c7bb68, phases=4) at 10.1/sql/sql_lex.cc:3591
#12 0x00007fb8fc2fdbbd in JOIN::optimize_inner (this=0x7fb8f0c8b1c0) at 10.1/sql/sql_select.cc:1082
#13 0x00007fb8fc2fd95e in JOIN::optimize (this=0x7fb8f0c8b1c0) at 10.1/sql/sql_select.cc:1021
#14 0x00007fb8fc305a70 in mysql_select (thd=0x7fb8f2ab2070, rref_pointer_array=0x7fb8f0c7c598, tables=0x7fb8f0c82188, wild_num=1, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147749632, result=0x7fb8f0c8b1a0, unit=0x7fb8f0c7bc30, select_lex=0x7fb8f0c7c320) at 10.1/sql/sql_select.cc:3309
#15 0x00007fb8fc2fbbbf in handle_select (thd=0x7fb8f2ab2070, lex=0x7fb8f0c7bb68, result=0x7fb8f0c8b1a0, setup_tables_done_option=0) at 10.1/sql/sql_select.cc:371
#16 0x00007fb8fc2bc071 in execute_sqlcom_select (thd=0x7fb8f2ab2070, all_tables=0x7fb8f0c82188) at 10.1/sql/sql_parse.cc:5805
#17 0x00007fb8fc2b24aa in mysql_execute_command (thd=0x7fb8f2ab2070) at 10.1/sql/sql_parse.cc:2937
#18 0x00007fb8fc61368c in sp_instr_stmt::exec_core (this=0x7fb8f0c82768, thd=0x7fb8f2ab2070, nextp=0x7fb8fbd19124) at 10.1/sql/sp_head.cc:3135
#19 0x00007fb8fc612dcb in sp_lex_keeper::reset_lex_and_exec_core (this=0x7fb8f0c827a8, thd=0x7fb8f2ab2070, nextp=0x7fb8fbd19124, open_tables=false, instr=0x7fb8f0c82768) at 10.1/sql/sp_head.cc:2901
#20 0x00007fb8fc613394 in sp_instr_stmt::execute (this=0x7fb8f0c82768, thd=0x7fb8f2ab2070, nextp=0x7fb8fbd19124) at 10.1/sql/sp_head.cc:3051
#21 0x00007fb8fc60efca in sp_head::execute (this=0x7fb8f0c7b088, thd=0x7fb8f2ab2070, merge_da_on_success=true) at 10.1/sql/sp_head.cc:1316
#22 0x00007fb8fc610e62 in sp_head::execute_procedure (this=0x7fb8f0c7b088, thd=0x7fb8f2ab2070, args=0x7fb8f2ab66b0) at 10.1/sql/sp_head.cc:2103
#23 0x00007fb8fc2b0c9d in do_execute_sp (thd=0x7fb8f2ab2070, sp=0x7fb8f0c7b088) at 10.1/sql/sql_parse.cc:2383
#24 0x00007fb8fc2b9d0e in mysql_execute_command (thd=0x7fb8f2ab2070) at 10.1/sql/sql_parse.cc:5180
#25 0x00007fb8fc2bf5de in mysql_parse (thd=0x7fb8f2ab2070, rawbuf=0x7fb8f0c22088 "CALL proc()", length=11, parser_state=0x7fb8fbd1a180) at 10.1/sql/sql_parse.cc:7181
#26 0x00007fb8fc2ae772 in dispatch_command (command=COM_QUERY, thd=0x7fb8f2ab2070, packet=0x7fb8f2ab8071 "CALL proc()", packet_length=11) at 10.1/sql/sql_parse.cc:1470
#27 0x00007fb8fc2ad49d in do_command (thd=0x7fb8f2ab2070) at 10.1/sql/sql_parse.cc:1093
#28 0x00007fb8fc3ee1f5 in do_handle_one_connection (thd_arg=0x7fb8f2ab2070) at 10.1/sql/sql_connect.cc:1350
#29 0x00007fb8fc3edf59 in handle_one_connection (arg=0x7fb8f2ab2070) at 10.1/sql/sql_connect.cc:1262
#30 0x00007fb8fcaa4f7c in pfs_spawn_thread (arg=0x7fb8f9023ff0) at 10.1/storage/perfschema/pfs.cc:1860
#31 0x00007fb8fa6bee9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#32 0x00007fb8f9debcbd in clone () from /lib/x86_64-linux-gnu/libc.so.6

Attachments

Activity

Ascending order - Click to sort in descending order

Elena Stepanova created issue - 2015-05-01 01:32

Elena Stepanova made changes - 2015-05-01 01:40

Field	Original Value	New Value
Attachment		mysql.err [ 37910 ]
Attachment		mysql.log [ 37911 ]

Elena Stepanova made changes - 2015-05-12 15:36

Fix Version/s

10.1 [ 16100 ]

Rasmus Johansson (Inactive) made changes - 2015-05-18 17:51

Workflow

MariaDB v2 [ 60746 ]

MariaDB v3 [ 62832 ]

Elena Stepanova added a comment - 2015-06-30 22:10

Please re-assign if needed.

Elena Stepanova added a comment - 2015-06-30 22:10 Please re-assign if needed.

Elena Stepanova made changes - 2015-06-30 22:10

Fix Version/s		10.1 [ 16100 ]
Assignee	Elena Stepanova [ elenst ]	Sergei Petrunia [ psergey ]
Description	{noformat} /home/elenst/git/10.1/sql/mysqld(my_print_stacktrace+0x38)[0x7f86c7185a4a] sql/signal_handler.cc:155(handle_fatal_signal)[0x7f86c6b41ed8] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f86c4d82cb0] sql/sql_analyze_stmt.h:89(Time_and_counter_tracker::incr_loops())[0x7f86c6993044] sql/sql_select.cc:2395(JOIN::exec())[0x7f86c6957aab] sql/sql_select.cc:3328(mysql_select(THD, Item*, TABLE_LIST, unsigned int, List<Item>&, Item, unsigned int, st_order, st_order, Item, st_order, unsigned long long, select_result, st_select_lex_unit, st_select_lex))[0x7f86c695b0f2] sql/sql_derived.cc:935(mysql_derived_fill(THD, LEX, TABLE_LIST))[0x7f86c68ef444] sql/sql_derived.cc:192(mysql_handle_single_derived(LEX, TABLE_LIST, unsigned int))[0x7f86c68edd33] sql/sql_select.cc:11507(st_join_table::preread_init())[0x7f86c69705f1] sql/sql_select.cc:17878(sub_select(JOIN, st_join_table, bool))[0x7f86c697f7cd] sql/sql_select.cc:17567(do_select(JOIN, List<Item>, TABLE, Procedure))[0x7f86c697f1cd] sql/sql_select.cc:3098(JOIN::exec_inner())[0x7f86c695a853] sql/sql_select.cc:2398(JOIN::exec())[0x7f86c6957b01] sql/sql_select.cc:3328(mysql_select(THD, Item**, TABLE_LIST, unsigned int, List<Item>&, Item, unsigned int, st_order, st_order, Item, st_order, unsigned long long, select_result, st_select_lex_unit, st_select_lex))[0x7f86c695b0f2] sql/sql_select.cc:373(handle_select(THD, LEX, select_result, unsigned long))[0x7f86c6951093] sql/sql_parse.cc:5782(execute_sqlcom_select(THD, TABLE_LIST))[0x7f86c6922305] sql/sql_parse.cc:2926(mysql_execute_command(THD))[0x7f86c6918862] sql/sp_head.cc:3130(sp_instr_stmt::exec_core(THD, unsigned int))[0x7f86c6c90460] sql/sp_head.cc:2896(sp_lex_keeper::reset_lex_and_exec_core(THD, unsigned int, bool, sp_instr))[0x7f86c6c8fb9f] sql/sp_head.cc:3046(sp_instr_stmt::execute(THD, unsigned int))[0x7f86c6c90168] sql/sp_head.cc:1313(sp_head::execute(THD, bool))[0x7f86c6c8bdb3] sql/sp_head.cc:2098(sp_head::execute_procedure(THD, List<Item>))[0x7f86c6c8dc36] sql/sql_parse.cc:2372(do_execute_sp(THD, sp_head))[0x7f86c6917055] sql/sql_parse.cc:5157(mysql_execute_command(THD))[0x7f86c691ffd8] sql/sql_parse.cc:7165(mysql_parse(THD, char, unsigned int, Parser_state))[0x7f86c692589b] sql/sql_parse.cc:1464(dispatch_command(enum_server_command, THD, char, unsigned int))[0x7f86c6914b4c] sql/sql_parse.cc:1090(do_command(THD))[0x7f86c6913927] sql/sql_connect.cc:1347(do_handle_one_connection(THD))[0x7f86c6a43e21] sql/sql_connect.cc:1259(handle_one_connection)[0x7f86c6a43b79] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f86c4d7ae9a] {noformat} {noformat} Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f8694c97088): SELECT COUNT(DISTINCT 2 ) INTO inout1 FROM view_1 Connection ID (thread ID): 21 Status: NOT_KILLED {noformat} Happened once so far, on 10.1 tree around commit 46816996 (possibly a few commits earlier). RQG revno 1016 {noformat} perl /home/elenst/bzr/randgen-mariadb-patches/runall-new.pl --no-mask --seed=1430171629 --threads=16 --duration=400 --queries=100M --reporters=QueryTimeout,Backtrace,ErrorLog,Deadlock --redefine=conf/mariadb/general-workarounds.yy --redefine=conf/mariadb/10.0-features-redefine.yy --mysqld=--log_output=FILE --mysqld=--slow_query_log --mysqld=--log_bin_trust_function_creators=1 --mysqld=--query_cache_size=64M --views --grammar=conf/runtime/metadata_stability.yy --gendata=conf/runtime/metadata_stability.zz --engine=InnoDB --rpl_mode=row --mysqld=--slave-skip-errors=1049,1305,1539,1505 --mysqld=--slave-parallel-mode=optimistic --mysqld=--slave-parallel-threads=20 --use-gtid=no --mtr-build-thread=73 --basedir1=/home/elenst/git/10.1 --vardir1=/home/elenst/test_results/10.1-parallel-replication-8/current1_1 {noformat}	_Note: unfortunately, I only have a concurrent test case. Run it with --repeat=N._ {code:sql} CREATE PROCEDURE proc() SELECT * FROM v2; --connect (con1,localhost,root,,test) CREATE ALGORITHM = UNDEFINED VIEW v1 AS SELECT 1; CREATE ALGORITHM = TEMPTABLE VIEW v2 AS SELECT 3 FROM v1; DROP VIEW v1; --error ER_VIEW_INVALID CALL proc(); --connection default --send CREATE ALGORITHM = TEMPTABLE VIEW v1 AS SELECT 2 --connection con1 CALL proc(); {code} {noformat:title=Stack trace from 1a3321b6496dcdbac47efb48e7b66aa23fd8e0f7} #3 <signal handler called> #4 0x00007fb8fc286e44 in Time_and_counter_tracker::incr_loops (this=0x68) at 10.1/sql/sql_analyze_stmt.h:89 #5 0x00007fb8fc3024c5 in JOIN::exec (this=0x7fb8f0c8bec0) at 10.1/sql/sql_select.cc:2391 #6 0x00007fb8fc305b03 in mysql_select (thd=0x7fb8f2ab2070, rref_pointer_array=0x7fb8f0c833c8, tables=0x7fb8f0c8e088, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2416185088, result=0x7fb8f0c8bdc8, unit=0x7fb8f0c82a60, select_lex=0x7fb8f0c83150) at 10.1/sql/sql_select.cc:3323 #7 0x00007fb8fc289302 in mysql_derived_fill (thd=0x7fb8f2ab2070, lex=0x7fb8f0c7bb68, derived=0x7fb8f0c82188) at 10.1/sql/sql_derived.cc:938 #8 0x00007fb8fc288e94 in mysql_derived_optimize (thd=0x7fb8f2ab2070, lex=0x7fb8f0c7bb68, derived=0x7fb8f0c82188) at 10.1/sql/sql_derived.cc:827 #9 0x00007fb8fc287bd7 in mysql_handle_single_derived (lex=0x7fb8f0c7bb68, derived=0x7fb8f0c82188, phases=4) at 10.1/sql/sql_derived.cc:195 #10 0x00007fb8fc3b6620 in TABLE_LIST::handle_derived (this=0x7fb8f0c82188, lex=0x7fb8f0c7bb68, phases=4) at 10.1/sql/table.cc:7090 #11 0x00007fb8fc2a5008 in st_select_lex::handle_derived (this=0x7fb8f0c7c320, lex=0x7fb8f0c7bb68, phases=4) at 10.1/sql/sql_lex.cc:3591 #12 0x00007fb8fc2fdbbd in JOIN::optimize_inner (this=0x7fb8f0c8b1c0) at 10.1/sql/sql_select.cc:1082 #13 0x00007fb8fc2fd95e in JOIN::optimize (this=0x7fb8f0c8b1c0) at 10.1/sql/sql_select.cc:1021 #14 0x00007fb8fc305a70 in mysql_select (thd=0x7fb8f2ab2070, rref_pointer_array=0x7fb8f0c7c598, tables=0x7fb8f0c82188, wild_num=1, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147749632, result=0x7fb8f0c8b1a0, unit=0x7fb8f0c7bc30, select_lex=0x7fb8f0c7c320) at 10.1/sql/sql_select.cc:3309 #15 0x00007fb8fc2fbbbf in handle_select (thd=0x7fb8f2ab2070, lex=0x7fb8f0c7bb68, result=0x7fb8f0c8b1a0, setup_tables_done_option=0) at 10.1/sql/sql_select.cc:371 #16 0x00007fb8fc2bc071 in execute_sqlcom_select (thd=0x7fb8f2ab2070, all_tables=0x7fb8f0c82188) at 10.1/sql/sql_parse.cc:5805 #17 0x00007fb8fc2b24aa in mysql_execute_command (thd=0x7fb8f2ab2070) at 10.1/sql/sql_parse.cc:2937 #18 0x00007fb8fc61368c in sp_instr_stmt::exec_core (this=0x7fb8f0c82768, thd=0x7fb8f2ab2070, nextp=0x7fb8fbd19124) at 10.1/sql/sp_head.cc:3135 #19 0x00007fb8fc612dcb in sp_lex_keeper::reset_lex_and_exec_core (this=0x7fb8f0c827a8, thd=0x7fb8f2ab2070, nextp=0x7fb8fbd19124, open_tables=false, instr=0x7fb8f0c82768) at 10.1/sql/sp_head.cc:2901 #20 0x00007fb8fc613394 in sp_instr_stmt::execute (this=0x7fb8f0c82768, thd=0x7fb8f2ab2070, nextp=0x7fb8fbd19124) at 10.1/sql/sp_head.cc:3051 #21 0x00007fb8fc60efca in sp_head::execute (this=0x7fb8f0c7b088, thd=0x7fb8f2ab2070, merge_da_on_success=true) at 10.1/sql/sp_head.cc:1316 #22 0x00007fb8fc610e62 in sp_head::execute_procedure (this=0x7fb8f0c7b088, thd=0x7fb8f2ab2070, args=0x7fb8f2ab66b0) at 10.1/sql/sp_head.cc:2103 #23 0x00007fb8fc2b0c9d in do_execute_sp (thd=0x7fb8f2ab2070, sp=0x7fb8f0c7b088) at 10.1/sql/sql_parse.cc:2383 #24 0x00007fb8fc2b9d0e in mysql_execute_command (thd=0x7fb8f2ab2070) at 10.1/sql/sql_parse.cc:5180 #25 0x00007fb8fc2bf5de in mysql_parse (thd=0x7fb8f2ab2070, rawbuf=0x7fb8f0c22088 "CALL proc()", length=11, parser_state=0x7fb8fbd1a180) at 10.1/sql/sql_parse.cc:7181 #26 0x00007fb8fc2ae772 in dispatch_command (command=COM_QUERY, thd=0x7fb8f2ab2070, packet=0x7fb8f2ab8071 "CALL proc()", packet_length=11) at 10.1/sql/sql_parse.cc:1470 #27 0x00007fb8fc2ad49d in do_command (thd=0x7fb8f2ab2070) at 10.1/sql/sql_parse.cc:1093 #28 0x00007fb8fc3ee1f5 in do_handle_one_connection (thd_arg=0x7fb8f2ab2070) at 10.1/sql/sql_connect.cc:1350 #29 0x00007fb8fc3edf59 in handle_one_connection (arg=0x7fb8f2ab2070) at 10.1/sql/sql_connect.cc:1262 #30 0x00007fb8fcaa4f7c in pfs_spawn_thread (arg=0x7fb8f9023ff0) at 10.1/storage/perfschema/pfs.cc:1860 #31 0x00007fb8fa6bee9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #32 0x00007fb8f9debcbd in clone () from /lib/x86_64-linux-gnu/libc.so.6 {noformat}

Elena Stepanova made changes - 2015-06-30 22:10

Attachment

mysql.log [ 37911 ]

Elena Stepanova made changes - 2015-06-30 22:10

Attachment

mysql.err [ 37910 ]

Elena Stepanova made changes - 2015-06-30 22:10

Summary

[Draft] Server crashed in Time_and_counter_tracker::incr_loops

Server crashed in Time_and_counter_tracker::incr_loops

Rasmus Johansson (Inactive) made changes - 2015-08-04 18:00

Sprint

10.1.7-1 [ 10 ]

Rasmus Johansson (Inactive) made changes - 2015-08-04 18:00

Rank

Ranked higher

Sergei Petrunia added a comment - 2015-08-07 20:20

Ok I was able to repeat.

It crashes when

"CALL proc()" executes

SELECT * FROM v2

which calls handle_derived() for v2

We reach JOIN::exec_inner() which has

  join->optimized=true

  join->have_query_plan == QEP_AVAILABLE

  join->join_tab[0] points to a heap table with alias="v1".

but
join->explain=NULL.

Sergei Petrunia added a comment - 2015-08-07 20:20 Ok I was able to repeat. It crashes when "CALL proc()" executes SELECT * FROM v2 which calls handle_derived() for v2 We reach JOIN::exec_inner() which has join->optimized=true join->have_query_plan == QEP_AVAILABLE join->join_tab[0] points to a heap table with alias="v1". but join->explain=NULL.

Sergei Petrunia added a comment - 2015-08-07 21:11

There is no crash when the queries are run serially. derived subqueries have degenerate joins but the code handles that situation.

Sergei Petrunia added a comment - 2015-08-07 21:11 There is no crash when the queries are run serially. derived subqueries have degenerate joins but the code handles that situation.

Sergei Petrunia added a comment - 2015-08-07 21:35

It's interesting that Explain data structure actually exists:

(gdb) p thd->lex->explain->get_node(2)

$17 = (Explain_select *) 0x7fffe001dde0

(gdb) p $17->message

$18 = 0x55555636d4dc "No tables used"

but it didn't get saved in join->explain.

Sergei Petrunia added a comment - 2015-08-07 21:35 It's interesting that Explain data structure actually exists: (gdb) p thd->lex->explain->get_node(2) $17 = (Explain_select *) 0x7fffe001dde0 (gdb) p $17->message $18 = 0x55555636d4dc "No tables used" but it didn't get saved in join->explain.

Sergei Petrunia added a comment - 2015-08-07 23:54

Added Explain_select::my_join to check how is it possible that Explain_select exists but join->explain==NULL.

(gdb) p thd->lex->explain->get_node(2)

$3 = (Explain_node *) 0x7fffe0030c50

(gdb) p $3->my_join

$4 = (void *) 0x7fffe002fdf8

(gdb) p this

$5 = (JOIN * const) 0x7fffe00304d0

So, there is a different JOIN object!

(gdb) p (class JOIN*) 0x7fffe002fdf8  ##this is $4

$6 = (JOIN *) 0x7fffe002fdf8

(gdb) p $6->select_lex

$7 = (SELECT_LEX *) 0x7fffe00329a8

(gdb) p this->select_lex

$8 = (SELECT_LEX *) 0x7fffe002a8c0

it has a different select_lex.

(gdb) p $6->select_lex->select_number

$9 = 2

(gdb) p this->select_lex->select_number

$10 = 2

both select_lex objects have id=2!

Sergei Petrunia added a comment - 2015-08-07 23:54 Added Explain_select::my_join to check how is it possible that Explain_select exists but join->explain==NULL. (gdb) p thd->lex->explain->get_node(2) $3 = (Explain_node *) 0x7fffe0030c50 (gdb) p $3->my_join $4 = (void *) 0x7fffe002fdf8 (gdb) p this $5 = (JOIN * const) 0x7fffe00304d0 So, there is a different JOIN object! (gdb) p (class JOIN*) 0x7fffe002fdf8 ##this is $4 $6 = (JOIN *) 0x7fffe002fdf8 (gdb) p $6->select_lex $7 = (SELECT_LEX *) 0x7fffe00329a8 (gdb) p this->select_lex $8 = (SELECT_LEX *) 0x7fffe002a8c0 it has a different select_lex. (gdb) p $6->select_lex->select_number $9 = 2 (gdb) p this->select_lex->select_number $10 = 2 both select_lex objects have id=2!

Sergei Golubchik made changes - 2015-08-18 21:00

Rank

Ranked higher

Elena Stepanova made changes - 2015-09-03 13:53

Assignee

Sergei Petrunia [ psergey ]

Oleksandr Byelkin [ sanja ]

Oleksandr Byelkin made changes - 2015-09-07 15:15

Status

Open [ 1 ]

In Progress [ 3 ]

Oleksandr Byelkin added a comment - 2015-09-07 17:26

1) I just lost moment when select number in the statement became ID. Different statement and the same number are possible
2) where the select belong to have to be important.
3) how we reached select of VIEW?

Oleksandr Byelkin added a comment - 2015-09-07 17:26 1) I just lost moment when select number in the statement became ID. Different statement and the same number are possible 2) where the select belong to have to be important. 3) how we reached select of VIEW?

Oleksandr Byelkin added a comment - 2015-09-07 17:55

Probably SELECT should be identified by LEX and its number in the request...

Oleksandr Byelkin added a comment - 2015-09-07 17:55 Probably SELECT should be identified by LEX and its number in the request...

Oleksandr Byelkin added a comment - 2015-09-08 12:36

As result with talking with Sergey Petrunia we've found that mysql_make_view renumbers SELECTs...

Ways:
1) make parser number views from mlast high number
2) find how it avoid renumbering

Oleksandr Byelkin added a comment - 2015-09-08 12:36 As result with talking with Sergey Petrunia we've found that mysql_make_view renumbers SELECTs... Ways: 1) make parser number views from mlast high number 2) find how it avoid renumbering

Oleksandr Byelkin added a comment - 2015-09-08 13:15

OK. Renumbering work as it should during parsing in mysql_make_view().

So problem probably in caching statement by SP and re-parsing views...

Oleksandr Byelkin added a comment - 2015-09-08 13:15 OK. Renumbering work as it should during parsing in mysql_make_view(). So problem probably in caching statement by SP and re-parsing views...

Rasmus Johansson (Inactive) made changes - 2015-09-09 10:49

Sprint

10.1.7-1 [ 10 ]

10.1.7-1, 10.1.8-1 [ 10, 13 ]

Oleksandr Byelkin made changes - 2015-09-09 13:56

Status

In Progress [ 3 ]

Stalled [ 10000 ]

Oleksandr Byelkin made changes - 2015-09-09 17:31

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Oleksandr Byelkin made changes - 2015-09-10 11:03

Status

In Progress [ 3 ]

Stalled [ 10000 ]

Oleksandr Byelkin made changes - 2015-09-10 17:58

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Oleksandr Byelkin made changes - 2015-09-14 10:51

Status

In Progress [ 3 ]

Stalled [ 10000 ]

Oleksandr Byelkin made changes - 2015-09-14 18:39

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Oleksandr Byelkin made changes - 2015-09-15 12:22

Status

In Progress [ 3 ]

Stalled [ 10000 ]

Sergei Golubchik made changes - 2015-09-16 00:22

Sprint

10.1.7-1, 10.1.8-1 [ 10, 13 ]

10.1.7-1, 10.1.8-1, 10.1.8-2 [ 10, 13, 14 ]

Sergei Golubchik made changes - 2015-09-16 00:22

Rank

Ranked higher

Oleksandr Byelkin added a comment - 2015-09-22 13:24

Problem is that in case VIEW is already processed it do not advance select_number counter in THD. Also the counter is not stored properly in the statement. So we get two selects #2 in case if ALTER is in time to fix the view.

Oleksandr Byelkin added a comment - 2015-09-22 13:24 Problem is that in case VIEW is already processed it do not advance select_number counter in THD. Also the counter is not stored properly in the statement. So we get two selects #2 in case if ALTER is in time to fix the view.

Oleksandr Byelkin added a comment - 2015-09-22 13:31

Sequential execution works because it makes full re-prepare of the procedure including views re-parsing, when in parallel execution one view is used as it was stored and other is parsed (and counter set wrongly).

Oleksandr Byelkin added a comment - 2015-09-22 13:31 Sequential execution works because it makes full re-prepare of the procedure including views re-parsing, when in parallel execution one view is used as it was stored and other is parsed (and counter set wrongly).

Oleksandr Byelkin added a comment - 2015-09-22 23:00

revision-id: a3c33026bc1f3a8efe3a165661786e7bc08bea34 (mariadb-10.1.6-108-ga3c3302)
parent(s): 20291639994beaa070b7228eafa7be31eb1d7ff8
committer: Oleksandr Byelkin
timestamp: 2015-09-22 21:59:18 +0200
message:

~~MDEV-8087~~: Server crashed in Time_and_counter_tracker::incr_loops

Problem:
Procedure which uses stack of views first executed without most deep view. It fails but one view cached.
Then simultaniusely create the view we lack and execute the procedure.
In the beginning of procedure execution views are not yet changes so procedure used as it was cached.
But by the time we are trying to use most deep view it is already created.
The problem with the view is that thd->select_number (first view was not parsed) so second view will get the same number.

The fix is in keeping the thd->select_number correct even if we use cached views.
In the proposed solution (to keep it simple) counter can be bigger then should but it should not create problem because numbers are still unique and situation is very rare.

—

Oleksandr Byelkin added a comment - 2015-09-22 23:00 revision-id: a3c33026bc1f3a8efe3a165661786e7bc08bea34 (mariadb-10.1.6-108-ga3c3302) parent(s): 20291639994beaa070b7228eafa7be31eb1d7ff8 committer: Oleksandr Byelkin timestamp: 2015-09-22 21:59:18 +0200 message: MDEV-8087 : Server crashed in Time_and_counter_tracker::incr_loops Problem: Procedure which uses stack of views first executed without most deep view. It fails but one view cached. Then simultaniusely create the view we lack and execute the procedure. In the beginning of procedure execution views are not yet changes so procedure used as it was cached. But by the time we are trying to use most deep view it is already created. The problem with the view is that thd->select_number (first view was not parsed) so second view will get the same number. The fix is in keeping the thd->select_number correct even if we use cached views. In the proposed solution (to keep it simple) counter can be bigger then should but it should not create problem because numbers are still unique and situation is very rare. —

Oleksandr Byelkin added a comment - 2015-09-22 23:03

Also the question is should we allow the situation when view changes and the procedure which uses it is not invalidated.

Situation is possible if we had problem with the view before and only when creating/altering view made in the same time with the procedure call but still can possibly bring some other problems.

Oleksandr Byelkin added a comment - 2015-09-22 23:03 Also the question is should we allow the situation when view changes and the procedure which uses it is not invalidated. Situation is possible if we had problem with the view before and only when creating/altering view made in the same time with the procedure call but still can possibly bring some other problems.

Oleksandr Byelkin made changes - 2015-09-22 23:04

Assignee	Oleksandr Byelkin [ sanja ]	Sergei Golubchik [ serg ]
Status	Stalled [ 10000 ]	In Review [ 10002 ]

Rasmus Johansson (Inactive) made changes - 2015-09-23 12:56

Sprint

10.1.7-1, 10.1.8-1, 10.1.8-2 [ 10, 13, 14 ]

10.1.7-1, 10.1.8-1, 10.1.8-3 [ 10, 13, 15 ]

Rasmus Johansson (Inactive) made changes - 2015-09-23 12:56

Rank

Ranked lower

Rasmus Johansson (Inactive) made changes - 2015-09-30 10:43

Rank

Ranked higher

Rasmus Johansson (Inactive) made changes - 2015-09-30 10:52

Sprint

10.1.7-1, 10.1.8-1, 10.1.8-3 [ 10, 13, 15 ]

10.1.7-1, 10.1.8-1, 10.1.8-3, 10.1.8-4 [ 10, 13, 15, 16 ]

Rasmus Johansson (Inactive) made changes - 2015-09-30 10:52

Rank

Ranked higher

Oleksandr Byelkin made changes - 2015-10-06 16:27

Assignee

Sergei Golubchik [ serg ]

Oleksandr Byelkin [ sanja ]

Oleksandr Byelkin made changes - 2015-10-06 16:27

Status

In Review [ 10002 ]

Stalled [ 10000 ]

Oleksandr Byelkin made changes - 2015-10-06 17:34

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Oleksandr Byelkin added a comment - 2015-10-06 20:59

fix with test suite:

revision-id: ccb6b0dd1fb603673dbcfe7d1763bd3fe5d3bcaf (mariadb-10.1.6-108-gccb6b0d)
parent(s): 20291639994beaa070b7228eafa7be31eb1d7ff8
committer: Oleksandr Byelkin
timestamp: 2015-10-06 19:54:56 +0200
message:

~~MDEV-8087~~: Server crashed in Time_and_counter_tracker::incr_loops

Problem:
Procedure which uses stack of views first executed without most deep view.
It fails but one view cached (as well as whole procedure).
Then simultaniusely create the second view we lack and execute the procedure.
In the beginning of procedure execution the view is not yet created so
procedure used as it was cached (cache was not invalidated).
But by the time we are trying to use most deep view it is already created.
The problem with the view is that thd->select_number (first view was not parsed) so second view will get the same number.

—

Oleksandr Byelkin added a comment - 2015-10-06 20:59 fix with test suite: revision-id: ccb6b0dd1fb603673dbcfe7d1763bd3fe5d3bcaf (mariadb-10.1.6-108-gccb6b0d) parent(s): 20291639994beaa070b7228eafa7be31eb1d7ff8 committer: Oleksandr Byelkin timestamp: 2015-10-06 19:54:56 +0200 message: MDEV-8087 : Server crashed in Time_and_counter_tracker::incr_loops Problem: Procedure which uses stack of views first executed without most deep view. It fails but one view cached (as well as whole procedure). Then simultaniusely create the second view we lack and execute the procedure. In the beginning of procedure execution the view is not yet created so procedure used as it was cached (cache was not invalidated). But by the time we are trying to use most deep view it is already created. The problem with the view is that thd->select_number (first view was not parsed) so second view will get the same number. The fix is in keeping the thd->select_number correct even if we use cached views. In the proposed solution (to keep it simple) counter can be bigger then should but it should not create problem because numbers are still unique and situation is very rare. —

Oleksandr Byelkin made changes - 2015-10-06 20:59

Status

In Progress [ 3 ]

Stalled [ 10000 ]

Oleksandr Byelkin made changes - 2015-10-06 21:00

Assignee	Oleksandr Byelkin [ sanja ]	Sergei Petrunia [ psergey ]
Status	Stalled [ 10000 ]	In Review [ 10002 ]

Sergei Petrunia added a comment - 2015-10-11 14:34

Ok to push

Sergei Petrunia added a comment - 2015-10-11 14:34 Ok to push

Sergei Petrunia made changes - 2015-10-11 14:34

Assignee	Sergei Petrunia [ psergey ]	Oleksandr Byelkin [ sanja ]
Status	In Review [ 10002 ]	Stalled [ 10000 ]

Oleksandr Byelkin made changes - 2015-10-12 12:48

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Oleksandr Byelkin made changes - 2015-10-12 13:09

Component/s		Parser [ 10201 ]
Fix Version/s		10.1.8 [ 19605 ]
Fix Version/s	10.1 [ 16100 ]
Resolution		Fixed [ 1 ]
Status	In Progress [ 3 ]	Closed [ 6 ]

Sergei Golubchik made changes - 2021-12-06 21:41

Workflow

MariaDB v3 [ 62832 ]

MariaDB v4 [ 149118 ]

People

Assignee:: Oleksandr Byelkin

Reporter:: Elena Stepanova

Votes:: 0 Vote for this issue

Watchers:: 4 Start watching this issue

Dates

Created:: 2015-05-01 01:32

Updated:: 2015-10-12 13:09

Resolved:: 2015-10-12 13:09

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server

Details

Description

Attachments

Activity

People

Dates

Git Integration