MySQL Bugs: #35936: Garbage in syntax error message

Bug #35936	Garbage in syntax error message
Submitted:	9 Apr 2008 12:50	Modified:	29 May 2008 3:50
Reporter:	Sven Sandberg	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Parser	Severity:	S2 (Serious)
Version:	6.0	OS:	Linux
Assigned to:	Marc ALFF	CPU Architecture:	Any
Tags:	bad memory address, corruption, parse error

Description:
If I run the following (syntactically incorrect) query:

SHOW NEW MASTER FOR SLAVE WITH;

Then I get the following error message:

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '7(�SHOW NEW MASTER' at line 1

Note the garbage inside the single-quotes near the end. Looks like we're reading a bad memory address.

The following queries give an empty string instead of the garbage:

SHOW NEW MASTER FOR SLAVE;
SHOW NEW MASTER FOR;
SHOW NEW MASTER;
SHOW NEW;
SHOW;

The empty string *could* be a sign of reading a bad memory address (typically, much of the memory is filled with '\0'), but it could also be that the parser isn't clever enough to find a better message than the empty string.

I get the empty string in 5.0 and 5.1 too (but no garbage). If the empty string is wrong, then we have this bug in 5.0 and 5.1 too.

I'm using the current rpl trees.

How to repeat:
SHOW NEW MASTER FOR SLAVE WITH;

Suggested fix:
?
Try running with Valgrind to find the bad pointer?

Thank you for the report.

Verified as described on Linux. On Mac and on Linux, but with other versions I get empty string instead of garbage.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/45796

ChangeSet@1.2623, 2008-04-21 17:37:29-06:00, malff@lambda.hsd1.co.comcast.net. +4 -0
  Bug#35936 (Garbage in syntax error message)
  
  Before this fix, the default initialization of
  Lex_input_stream::lookahead_token was using the value END_OF_INPUT
  to represent that no lookahead token has been parsed.
  
  This choice was unfortunate, since END_OF_INPUT is a real token value
  that can be returned by the lexer, which caused confusion when a query contains
  the following tokens:
    <WITH> <END_OF_INPUT>
  which in turn happens when a (malformed) query ends with <WITH>.
  
  Changed the value that represents "no token" to an out-of-bound token value,
  (-1), that can not be returned by the lexer.

Pushed into 6.0.6-alpha

Noted in 6.0.6 changelog.

Some syntactically invalid statements could cause the server to
return an error message containing garbage characters.