Sporadic bug in threadpool leading to handle_fatal_signal (sig=11) in set_null
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Percona Server moved to https://jira.percona.com/projects/PS | Status tracked in 5.7 | |||||
5.5 |
Triaged
|
High
|
Unassigned | |||
5.6 |
New
|
Undecided
|
Unassigned | |||
5.7 |
New
|
Undecided
|
Unassigned |
Bug Description
[...]
InnoDB: DEBUG: update_statistics for test/ti.
InnoDB: DEBUG: update_statistics for test/t.
InnoDB: DEBUG: update_statistics for test/ti.
00:29:39 UTC - 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,
Core was generated by `/sda/PS091117-
Program terminated with signal 11, Segmentation fault.
#0 0x00007fdfce3729b1 in __pthread_kill (threadid=
at ../nptl/
61 val = INTERNAL_SYSCALL (tgkill, err, 3, THREAD_GETMEM (THREAD_SELF, pid),
(gdb) bt
#0 0x00007fdfce3729b1 in __pthread_kill (threadid=
at ../nptl/
#1 0x00000000007f9bc8 in my_write_core (sig=11) at /home/roel/
#2 0x00000000006b9803 in handle_fatal_signal (sig=11) at /home/roel/
#3 <signal handler called>
#4 0x00000000006b4d0c in set_null (row_offset=0, this=0x7fdfaa04
#5 set_field_
at /home/roel/
#6 0x00000000006c94fc in Item_field:
at /home/roel/
#7 0x00000000006d8cac in Item_insert_
no_
#8 0x0000000000553202 in fill_record (thd=thd@
ignore_
#9 0x00000000005532a9 in fill_record_
ignore_
at /home/roel/
#10 0x000000000057ebc7 in select_
at /home/roel/
#11 0x0000000000581414 in select_
at /home/roel/
#12 0x00000000005d156e in end_send (join=0x7fdfa68
at /home/roel/
#13 0x00000000005c5096 in evaluate_
error=
#14 0x00000000005c52d3 in sub_select (join=join@
end_
#15 0x00000000005ce925 in do_select (join=join@
procedure=0x0) at /home/roel/
#16 0x00000000005e2a63 in JOIN::exec (this=this@
#17 0x00000000005dca23 in mysql_select (thd=thd@
tables=
proc_param=0x0, select_
0x7fdfb2bdfd28, select_
#18 0x00000000005dcc61 in handle_select (thd=thd@
result=
at /home/roel/
#19 0x00000000005981d2 in mysql_execute_
#20 0x000000000059ec81 in mysql_parse (thd=thd@
parser_
#21 0x00000000005a0721 in dispatch_command (command=
packet=
packet_
#22 0x00000000005a256f in do_command (thd=thd@
#23 0x0000000000674949 in threadpool_
#24 0x0000000000694666 in handle_event (connection=
#25 worker_main (param=0x117e800 <all_groups+3072>) at /home/roel/
#26 0x00007fdfce36de25 in start_thread (arg=0x7fdfcb1f
#27 0x00007fdfccb6b34d in clone () at ../sysdeps/
Testcase;
1) Note this bug is sporadic. However, it usually reproduces in 5-15 attempts (cursor up>enter>cursor up>enter etc. until status 256 output of pquery is seen instead of status 0)
2) Reproducibility may be different on different systems (i.e. >15 attempts may be needed, I included a while loop below for ease of use)
3) This only replays via mysqlclient API calls (i.e. pquery)
4) Actual testcase;
The attached tarball (1512603735_ bug_bundle. tar.gz) gives the testcase as an exact match of our system, including some handy utilities
$ vi 1512603735_mybase # STEP1: Update the base path in this file (usually the only change required!). If you use a non-binary distribution, please update SOURCE_DIR location also run_pquery # STEP5: Run the testcase with the pquery binary 1512603735/ error.log. out # STEP6: Verify the error log parse_core # OPTIONAL: Creates 1512603735_STD.gdb and 1512603735_ FULL.gdb; standard and full variables gdb stack traces
$ ./1512603735_init # STEP2: Initializes the data dir
$ ./1512603735_start # STEP3: Starts mysqld
$ ./1512603735_cl # STEP4: To check mysqld is up
$ ./1512603735_
$ vi /dev/shm/
$ ./1512603735_gdb # OPTIONAL: Brings you to a gdb prompt with gdb attached to the used mysqld and attached to the generated core
$ ./1512603735_
while [ 1 -eq 1 ]; do ./1512603735_ run_pquery ;done # To loop (or just do manually 5-15 times)