Welcome to the 10th episode in the MySQL QA series! Today we’ll talk about reproducing and simplifying: How to get it Right.
Note that unless you are a QA engineer stuck on a remote, and additionally difficult-to-reproduce or difficult-to-reduce bug, this episode will largely be non-interesting for you.
However, what you may like to see – especially if you watched episodes 7 (and possibly 8 and 9) – is how reducer automatically generates handy start/stop/client (cl) etc. scripts, all packed into a handy bug tarball, in combination with the reduced SQL testcase.
This somewhat separate part is covered directly after the introduction (ends at 11:17), as well as with an example towards the end of the video (starts at time index 30:35).
The “in between part” (11:17 to 30:35) is all about reproducing and simplifying, which – unless you are working on a remote case – can likely be skipped by most; remember that 85-95% of bugs reproduce & reduce very easily – and for this – episode 7, episode 8 (especially the FORCE_SKIPV/FORCE_SPORADIC parts), and the script-related parts of this episode (start to 11:17 and 30:35 to end) would suffice.
As per the above, the topics covered in this video are:
1. percona-qa/reproducing_and_simplification.txt
2. Automatically generated scripts (produced by Reducer)
========= Example bug excerpt for copy/paste – as per the video
Though the testcase above should suffice for reproducing the bug, the attached tarball gives the testcase as an exact match of our system, including some handy utilities
$ vi {epoch}_mybase # Update base path in this file (the only change required!)
$ ./{epoch}_init # Initializes the data dir
$ ./{epoch}_start # Starts mysqld (MYEXRA –option)
$ ./{epoch}_stop # Stops mysqld
$ ./{epoch}_cl # To check mysqld is up
$ ./{epoch}_run # Run the testcase (produces output) using mysql CLI
$ ./{epoch}_run_pquery # Run the testcase (produces output) using pquery
$ vi /dev/shm/{epoch}/error.log.out # Verify the error log
$ ./{epoch}_gdb # Brings you to a gdb prompt
$ ./{epoch}_parse_core # Create {epoch}_STD.gdb and {epoch}_FULL.gdb; standard and full var gdb stack traces
Full-screen viewing @ 720p resolution recommended
You can view the full series here: https://www.percona.com/blog/2015/03/17/free-mysql-qa-and-bash-linux-training-series
Thank you again for detailed explanation. So the steps we should take for reproducing are:
1. 14xxx_init
2.14xxx_start
3. 14xxx_cl -> for checking it is up or not
4. 14xxx_run or (run_pquery)
5. 14xxx_gdb
6. 14xxx_parse_core
So 14xxx_run.sh is just running generated SQL file as input file using mysql client:
${MYBASE}/bin/mysql -uroot –binary-mode –force -S/dev/shm/1440150447/socket.sock is a binary file]
It is calling pquery-run.sh and assigns 1440150447.sql as INFILE? (INFILE=${SCRIPT_PWD}/pquery/5.7.7.sql)
@Shahriyar the _run and _run_pquery call the mysql client and the pquery client respectively, and INFILE is passed to them. pquery-run.sh itself is used for the overall run, whereas these scripts are generated by reducer, per-trial (i.e. the trials as created by pquery-run.sh/pquery-prep-red.sh).
@All, please note we have moved percona-qa to GitHub:
https://github.com/Percona-QA/percona-qa
To clone it, use:
$ sudo yum install git
$ cd ~
$ git clone https://github.com/Percona-QA/percona-qa.git
reducer.sh was also put directly into this repository (and it is maintained there), so *no* need anymore to separately fetch lp:randgen.