EmergencyEMERGENCY? Get 24/7 Help Now!

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

 | July 31, 2015 |  Posted In: Insight for DBAs, Insight for Developers, MySQL, Quality Assurance

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
Roel Van de Paar

Roel leads Percona's QA team. Before coming to Percona, he contributed significantly to the QA infrastructure at Oracle. Roel has a varied background in IT, backed up by many industry leading certifications. He also enjoys time with God, his wife and 5 children, or heading into nature.

3 Comments

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

Leave a Reply