MySQL QA Episode 10: Reproducing and Simplifying: How to get it Right

MySQL QA Episode 10: Reproducing and Simplifying: How to get it Right

PREVIOUS POST
NEXT POST

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

PREVIOUS POST
NEXT POST

Share this post

Comments (3)

  • Shahriyar Rzayev Reply

    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)

    August 23, 2015 at 7:07 am
  • Roel Van de Paar Reply

    @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.

    November 26, 2015 at 1:00 am

Leave a Reply