Non-ASCII rendering of apostrophe in LOCK TABLES FOR BACKUP error message

[Roel Van de Paar]

Testcase:

LOCK TABLES FOR BACKUP;
CREATE VIEW a AS SELECT *;

Result:

mysql> CREATE VIEW a AS SELECT *;
ERROR 1884 (HY000): Can't execute the query because you have a conflicting backup lock

Which at first sight looks perfectly normal. Yet, tee (mysql CLI TEE command) the output and hexdump it. Notice (** highlight added):

[roel@localhost Percona-Server-5.6.19-rel67.0-648-debug.Linux.x86_64]$ hexdump -C out.txt
000000f0 53 20 53 45 4c 45 43 54 20 2a 3b 0a 45 52 52 4f |S SELECT *;.ERRO|
00000100 52 20 31 38 38 34 20 28 48 59 30 30 30 29 3a 20 |R 1884 (HY000): |
00000110 43 61 6e **e2 80 99** 74 20 65 78 65 63 75 74 65 20 |Can...t execute | <------ (!!)
00000120 74 68 65 20 71 75 65 72 79 20 62 65 63 61 75 73 |the query becaus|
00000130 65 20 79 6f 75 20 68 61 76 65 20 61 20 63 6f 6e |e you have a con|
00000140 66 6c 69 63 74 69 6e 67 20 62 61 63 6b 75 70 20 |flicting backup |
00000150 6c 6f 63 6b 0a 6d 79 73 71 6c 3e 20 65 78 69 74 |lock.mysql> exit|
00000160 0a 0a 45 52 52 4f 52 20 31 38 38 34 20 28 48 59 |..ERROR 1884 (HY|
00000170 30 30 30 29 3a 20 43 61 6e **27** 74 20 65 78 65 63 |000): Can't exec| <------ (!)
00000180 75 74 65 20 74 68 65 20 71 75 65 72 79 20 62 65 |ute the query be|
00000190 63 61 75 73 65 20 79 6f 75 20 68 61 76 65 20 61 |cause you have a|
000001a0 20 63 6f 6e 66 6c 69 63 74 69 6e 67 20 62 61 63 | conflicting bac|

The (!!) part is the CLI TEE dump of the command, the (!) one is just a copy/paste in the out.txt file and replacing the ' that is there with a normal ASCII '.

So, it looks like a duck, it waggles like a duck and it kweks like a duck, but it's not a duck :) This was a fun bug to find :)

This causes STATUS_DATABASE_CORRUPTION RQG errors;

# 2014-08-25T17:46:48 Query: CREATE VIEW m AS SELECT * FROM `E` failed: 1884 Can<92>t execute the query because you have a conflicting backup lock
# 2014-08-25T17:46:48 Error: 'Can<92>t execute the query because you have a conflicting backup lock' indicates memory corruption. Note that this may be a false alarm if the test contains non-ascii character sets and non-alphanumeric characters.
# 2014-08-25T17:46:49 Killing periodic reporting process with pid 3538...
# 2014-08-25T17:46:49 Kill GenTest::ErrorFilter(3537)
# 2014-08-25T17:46:49 Test completed with failure status STATUS_DATABASE_CORRUPTION (105)

And is a QA blocker bug.

(In RQG, the ErrorMessageCorruption.pm sees the non-ASCII characters and reports it as corruption - even if incorrectly reported as DB corruption). It may still be memory corruption, though it's like just a error text typo or similar.

[Alexey Kopytov (akopytov)]

It's an RQG bug. Detecting "database corruption" by unicode characters in an error message is a bit naive. Unicode characters are valid in error messages.

[Laurynas Biveinis (laurynas-biveinis)]

It is an RQG bug indeed. But is there a good reason for having a non-ASCII apostrophe there? It diffs poorly for one thing, as fixing the bug has shown.

[Alexey Kopytov (akopytov)]

I don't see any problems with diff. In fact, the character is not even unicode, but is extended ASCII.

[Laurynas Biveinis (laurynas-biveinis)]

In MTR result files it diffs showing the extended ASCII code:

-ERROR HY000: Can<92>t execute the query because you have a conflicting backup lock
+ERROR HY000: Can't execute the query because you have a conflicting backup lock

in the error message file it diffs showing the three UTF-8 bytes:

- eng "Can<E2><80><99>t execute the query because you have a conflicting backup lock"
+ eng "Can't execute the query because you have a conflicting backup lock"

[Alexey Kopytov (akopytov)]

That's correct, because in errmsg-utf8.txt it is stored in, well, UTF-8.

MTR executes tests with the default character set (latin1), so the unicode character is converted to it's extended ASCII equivalent, which is also present in latin1.

[Roel Van de Paar (roel11)]

[share]$ cat errmsg-utf8.txt | grep "execute the query because you"
        eng "Can't execute the query because you have a conflicting read lock"
        eng "Can't execute the query because you have a conflicting backup lock"

[share]$ cat errmsg-utf8.txt | grep "execute the query because you" | hexdump -C
00000000 20 20 20 20 20 20 20 20 65 6e 67 20 22 43 61 6e | eng "Can|
00000010 27 74 20 65 78 65 63 75 74 65 20 74 68 65 20 71 |'t execute the q| <--- 1 byte, fine
00000020 75 65 72 79 20 62 65 63 61 75 73 65 20 79 6f 75 |uery because you|
00000030 20 68 61 76 65 20 61 20 63 6f 6e 66 6c 69 63 74 | have a conflict|
00000040 69 6e 67 20 72 65 61 64 20 6c 6f 63 6b 22 0a 09 |ing read lock"..|
00000050 65 6e 67 20 22 43 61 6e e2 80 99 74 20 65 78 65 |eng "Can...t exe| <--- 3 bytes
00000060 63 75 74 65 20 74 68 65 20 71 75 65 72 79 20 62 |cute the query b|
00000070 65 63 61 75 73 65 20 79 6f 75 20 68 61 76 65 20 |ecause you have |
00000080 61 20 63 6f 6e 66 6c 69 63 74 69 6e 67 20 62 61 |a conflicting ba|
00000090 63 6b 75 70 20 6c 6f 63 6b 22 0a |ckup lock".|
0000009b

[Roel Van de Paar (roel11)]

Every other ' in the file is correct.

[roel@localhost share]$ cat errmsg-utf8.txt | grep -i "Can.t" | hexdump -C | grep -i "Can.t" | wc -l
58
[roel@localhost share]$ cat errmsg-utf8.txt | grep -i "Can.t" | hexdump -C | grep -i "Can...t" | wc -l
1

[Roel Van de Paar (roel11)]

Without this fix QA will remove LOCK TABLES FOR BACKUP testing from RQG as we are not at liberty to change RQG in this area (nor would we - see MS Bugs 42685 and 47412 which clearly show this not to be a naive idea)

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-3177