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

Bug #1360942 reported by Roel Van de Paar on 2014-08-24
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server
Undecided
Unassigned
5.1
Undecided
Unassigned
5.5
Undecided
Unassigned
5.6
Undecided
Unassigned

Bug Description

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.

description: updated
description: updated
tags: added: low-hanging-fruit
Alexey Kopytov (akopytov) wrote :

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.

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) wrote :

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

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) wrote :

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) wrote :

[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) wrote :

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) wrote :

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)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers