Non-ASCII rendering of apostrophe in LOCK TABLES FOR BACKUP error message
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Percona Server moved to https://jira.percona.com/projects/PS |
Invalid
|
Undecided
|
Unassigned | |
| 5.1 |
Invalid
|
Undecided
|
Unassigned | |
| 5.5 |
Invalid
|
Undecided
|
Unassigned | |
| 5.6 |
Invalid
|
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-
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_
# 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:
# 2014-08-25T17:46:49 Test completed with failure status STATUS_
And is a QA blocker bug.
(In RQG, the ErrorMessageCor
Related branches
description: | updated |
description: | updated |
tags: | added: low-hanging-fruit |
Alexey Kopytov (akopytov) wrote : | #1 |
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 : | #3 |
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 : | #5 |
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 : | #6 |
[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 : | #7 |
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 : | #8 |
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) wrote : | #9 |
Percona now uses JIRA for bug reports so this bug report is migrated to: https:/
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.