Bug#26503 (Illegal SQL exception handler code causes the server to crash)

Before this fix, the parser would accept illegal code in SQL exceptions
handlers, that later causes the runtime to crash when executing the code,
due to memory violations in the exception handler stack.

The root cause of the problem is instructions within an exception handler
that jumps to code located outside of the handler. This is illegal according
to the SQL 2003 standard, since labels located outside the handler are not
supposed to be visible (they are "out of scope"), so any instruction that
jumps to these labels, like ITERATE or LEAVE, should not parse.

The section of the standard that is relevant for this is :
  SQL:2003 SQL/PSM (ISO/IEC 9075-4:2003)
  section 13.1 <compound statement>,
  syntax rule 4
<quote>
  The scope of the <beginning label> is CS excluding every <SQL schema
  statement> contained in CS and excluding every
  <local handler declaration list> contained in CS. <beginning label> shall
  not be equivalent to any other <beginning label>s within that scope.
</quote>

With this fix, the C++ class sp_pcontext, which represent the "parsing
context" tree (a.k.a symbol table) of a stored procedure, has been changed
as follows:
- constructors have been cleaned up, so that only building a root node for
the tree is public; building nodes inside a tree is not public.
- a new member, m_label_scope, indicates if a given syntactic context
belongs to a DECLARE HANDLER block,
- label resolution, in the method find_label(), has been changed to
implement the restriction of scope regarding labels used in a compound
statement.

The actions in the parser, when parsing the body of a SQL exception handler,
have been changed as follows:
- the implementation of an exception handler (DECLARE HANDLER) now creates
explicitly a new sp_pcontext, to isolate the code inside the handler from
the containing compound statement context.
- registering exception handlers as a result occurs in the parent context,
see the rule sp_hcond_element
- the code in sp_hcond_list has been cleaned up, to avoid code duplication

In addition, the flags IN_SIMPLE_CASE and IN_HANDLER, declared in sp_head.h
have been removed, since they are unused and broken by design (as seen with
Bug 19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation), representing a stack in a single flag is not possible.

Tests in sp-error have been added to show that illegal constructs are now
rejected.

Tests in sp have been added for code coverage, to show that ITERATE or LEAVE
statements are legal when jumping to a label in scope, inside the body of
an exception handler.


mysql-test/r/sp-error.result:
  SQL Exception handlers define a parsing context for label resolution.
mysql-test/r/sp.result:
  SQL Exception handlers define a parsing context for label resolution.
mysql-test/t/sp-error.test:
  SQL Exception handlers define a parsing context for label resolution.
mysql-test/t/sp.test:
  SQL Exception handlers define a parsing context for label resolution.
sql/sp_head.cc:
  Minor cleanup
sql/sp_head.h:
  Minor cleanup
sql/sp_pcontext.cc:
  SQL Exception handlers define a parsing context for label resolution.
sql/sp_pcontext.h:
  SQL Exception handlers define a parsing context for label resolution.
sql/sql_yacc.yy:
  SQL Exception handlers define a parsing context for label resolution.

1 files changed, 0 insertions, 2 deletions

diff --git a/sql/sp_head.h b/sql/sp_head.h
index 4ef4077cc79..901b7a19c39 100644
--- a/sql/sp_head.h
+++ b/sql/sp_head.h
@@ -107,8 +107,6 @@ public:
   /* Possible values of m_flags */
   enum {
     HAS_RETURN= 1,              // For FUNCTIONs only: is set if has RETURN
-    IN_SIMPLE_CASE= 2,          // Is set if parsing a simple CASE
-    IN_HANDLER= 4,              // Is set if the parser is in a handler body
     MULTI_RESULTS= 8,           // Is set if a procedure with SELECT(s)
     CONTAINS_DYNAMIC_SQL= 16,   // Is set if a procedure with PREPARE/EXECUTE
     IS_INVOKED= 32,             // Is set if this sp_head is being used