Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Won't Fix
-
10.2(EOL)
Description
The issue appears to be 10.2-only and debug-only, so I don't expect it to be fixed, but it has to be filed.
Execute from MTR with --ps-protocol.
/*!100102 SET STATEMENT LOCK_WAIT_TIMEOUT= 1 FOR */ SELECT 1; |
select 2; |
The second select doesn't affect the outcome, but it seems to help to get a coredump, otherwise the server tends to die in the middle of writing a crash report in the error log, without a coredump.
|
10.2 fb9d1519 |
mysqld: /data/src/10.2/sql/sql_lex.h:2926: void LEX::free_set_stmt_mem_root(): Assertion `!is_arena_for_set_stmt()' failed.
|
210404 2:55:09 [ERROR] mysqld got signal 6 ;
|
 |
#7 0x00007f9cb1b57f36 in __GI___assert_fail (assertion=0x5595de1218bb "!is_arena_for_set_stmt()", file=0x5595de121865 "/data/src/10.2/sql/sql_lex.h", line=2926, function=0x5595de121898 "void LEX::free_set_stmt_mem_root()") at assert.c:101
|
#8 0x00005595dd61bab2 in LEX::free_set_stmt_mem_root (this=0x7f9c9407d868) at /data/src/10.2/sql/sql_lex.h:2926
|
#9 0x00005595dd61bca8 in LEX::~LEX (this=0x7f9c9407d868, __in_chrg=<optimized out>) at /data/src/10.2/sql/sql_lex.h:2939
|
#10 0x00005595dd61dec0 in st_lex_local::~st_lex_local (this=0x7f9c9407d868, __in_chrg=<optimized out>) at /data/src/10.2/sql/sql_lex.h:3387
|
#11 0x00005595dd61dee0 in st_lex_local::~st_lex_local (this=0x7f9c9407d868, __in_chrg=<optimized out>) at /data/src/10.2/sql/sql_lex.h:3387
|
#12 0x00005595dd6ef23f in Prepared_statement::~Prepared_statement (this=0x7f9c940068b0, __in_chrg=<optimized out>) at /data/src/10.2/sql/sql_prepare.cc:4082
|
#13 0x00005595dd6ef2b4 in Prepared_statement::~Prepared_statement (this=0x7f9c940068b0, __in_chrg=<optimized out>) at /data/src/10.2/sql/sql_prepare.cc:4086
|
#14 0x00005595dd681545 in delete_statement_as_hash_key (key=0x7f9c940068b0) at /data/src/10.2/sql/sql_class.cc:3642
|
#15 0x00005595de079a34 in my_hash_delete (hash=0x7f9c94002838, record=0x7f9c940068b0 "\350\\s\336\225U") at /data/src/10.2/mysys/hash.c:632
|
#16 0x00005595dd681883 in Statement_map::erase (this=0x7f9c94002838, statement=0x7f9c940068b0) at /data/src/10.2/sql/sql_class.cc:3757
|
#17 0x00005595dd6f2197 in Prepared_statement::deallocate (this=0x7f9c940068b0) at /data/src/10.2/sql/sql_prepare.cc:5202
|
#18 0x00005595dd6ee382 in mysqld_stmt_close (thd=0x7f9c94000d90, packet=0x7f9c94008b51 "\001") at /data/src/10.2/sql/sql_prepare.cc:3720
|
#19 0x00005595dd6c1354 in dispatch_command (command=COM_STMT_CLOSE, thd=0x7f9c94000d90, packet=0x7f9c94008b51 "\001", packet_length=4, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1790
|
#20 0x00005595dd6c015f in do_command (thd=0x7f9c94000d90) at /data/src/10.2/sql/sql_parse.cc:1381
|
#21 0x00005595dd81ac94 in do_handle_one_connection (connect=0x5595e011f120) at /data/src/10.2/sql/sql_connect.cc:1336
|
#22 0x00005595dd81a9f9 in handle_one_connection (arg=0x5595e011f120) at /data/src/10.2/sql/sql_connect.cc:1241
|
#23 0x00005595de044f16 in pfs_spawn_thread (arg=0x5595e0102800) at /data/src/10.2/storage/perfschema/pfs.cc:1869
|
#24 0x00007f9cb2069609 in start_thread (arg=<optimized out>) at pthread_create.c:477
|
#25 0x00007f9cb1c43293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
|
No obvious immediate problem on non-debug builds.
Not reproducible on 10.3+, including very old 10.3.6.