mariadb

Tree: b2f8005094

Author	SHA1	Message	Date
Alexander Nozdrin	b2f8005094	Auto-merge from mysql-trunk-bugfixing. ****** This patch fixes the following bugs: - Bug#5889: Exit handler for a warning doesn't hide the warning in trigger - Bug#9857: Stored procedures: handler for sqlwarning ignored - Bug#23032: Handlers declared in a SP do not handle warnings generated in sub-SP - Bug#36185: Incorrect precedence for warning and exception handlers The problem was in the way warnings/errors during stored routine execution were handled. Prior to this patch the logic was as follows: - when a warning/an error happens: if we're executing a stored routine, and there is a handler for that warning/error, remember the handler, ignore the warning/error and continue execution. - after a stored routine instruction is executed: check for a remembered handler and activate one (if any). This logic caused several problems: - if one instruction generates several warnings (errors) it's impossible to choose the right handler -- a handler for the first generated condition was chosen and remembered for activation. - mess with handling conditions in scopes different from the current one. - not putting generated warnings/errors into Warning Info (Diagnostic Area) is against The Standard. The patch changes the logic as follows: - Diagnostic Area is cleared on the beginning of each statement that either is able to generate warnings, or is able to work with tables. - at the end of a stored routine instruction, Diagnostic Area is left intact. - Diagnostic Area is checked after each stored routine instruction. If an instruction generates several condition, it's now possible to take a look at all of them and determine an appropriate handler.	16 years ago
malff@lambda.hsd1.co.comcast.net.	0a2e401c0a	Bug#20906 (Multiple assignments in SET in stored routine produce incorrect instructions) This bug can not be reproduced in the current version, adding the test case to the test suite for coverage, no code change.	18 years ago
malff@lambda.hsd1.co.comcast.net.	c3ad0cac75	Bug#33618 (Crash in sp_rcontext) Bug 33983 (Stored Procedures: wrong end <label> syntax is accepted) The server used to crash when REPEAT or another control instruction was used in conjunction with labels and a LEAVE instruction. The crash was caused by a missing "pop" of handlers or cursors in the code representing the stored program. When executing the code in a loop, this missing "pop" would result in a stack overflow, corrupting memory. Code generation has been fixed to produce the missing h_pop/c_pop instructions. Also, the logic checking that labels at the beginning and the end of a statement are matched was incorrect, causing Bug 33983. End labels, when used, must match the label used at the beginning of a block.	18 years ago
msvensson@pilot.(none)	599ec2f825	Remove "is_debug_build.inc" and use already existing "have-debug.inc"	19 years ago
thek@adventure.(none)	ae10d3d9e2	Bug#26977 exception handlers never hreturn - In some cases, flow control optimization implemented in sp::optimize removes hreturn instructions, causing SQL exception handlers to: * never return * execute wrong logic - This patch overrides default short cut optimization on hreturn instructions to avoid this problem.	19 years ago
gkodinov/kgeorge@magare.gmz[kgeorge]	9348841346	Bug #26303 : Reserve is not called before qs_append(). This may lead to buffer overflow. The String::qs_append() function will append a string without checking if there's enough space. So qs_append() must be called beforehand to ensure there's enough space in the buffer for the subsequent qs_append() calls. Fixed Item_case_expr::print() to make sure there's enough space before appending data by adding a call to String::reserve() to make sure qs_append() will have enough space.	19 years ago
malff/marcsql@weblab.(none)	ce5a3fcca8	Bug#19194 (Right recursion in parser for CASE causes excessive stack usage, limitation) Note to the reviewer ==================== Warning: reviewing this patch is somewhat involved. Due to the nature of several issues all affecting the same area, fixing separately each issue is not practical, since each fix can not be implemented and tested independently. In particular, the issues with - rule recursion - nested case statements - forward jump resolution (backpatch list) are tightly coupled (see below). Definitions =========== The expression CASE expr WHEN expr THEN expr WHEN expr THEN expr ... END is a "Simple Case Expression". The expression CASE WHEN expr THEN expr WHEN expr THEN expr ... END is a "Searched Case Expression". The statement CASE expr WHEN expr THEN stmts WHEN expr THEN stmts ... END CASE is a "Simple Case Statement". The statement CASE WHEN expr THEN stmts WHEN expr THEN stmts ... END CASE is a "Searched Case Statement". A "Left Recursive" rule is like list: element \| list element ; A "Right Recursive" rule is like list: element \| element list ; Left and right recursion produces the same language, the difference only affects the order in which the text is parsed. In a descendant parser (usually written manually), right recursion works very well, and is typically implemented with a while loop. In an ascendant parser (yacc/bison) left recursion works very well, and is implemented naturally by the parser stack. In both cases, using the wrong type or recursion is very bad and should be avoided, as it causes technical issues with the parser implementation. Before this change ================== The "Simple Case Expression" and "Searched Case Expression" were both implemented by the "when_list" and "when_list2" rules, which are left recursive (ok). These rules, however, used lex->when_list instead of using the parser stack, which is more complex that necessary, and potentially dangerous because of other rules using THD::reset_lex. The "Simple Case Statement" and "Searched Case Statements" were implemented by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules. Both cases were right recursive (bad). The grammar involved was convoluted, and is assumed to be the results of tweaks to get the code generation to work, but is not what someone would naturally write. In addition, using a common rule for both "Simple" and "Searched" case statements was implemented with sp_head::m_flags \|= IN_SIMPLE_CASE, which is a flag and not a stack, and therefore does not take into account nested case statements. This leads to incorrect generated code, and either a server crash or an incorrect result. With regards to the backpatch mechanism, a different backpatch list was created for each jump from "WHEN expr THEN stmt" to "END CASE", which relied on the grammar to be right recursive. This is a mis-use of the backpatch list, since this list can resolve multiple references to the same target at once. The optimizer algorithm used to detect dead code in the "assembly" SQL instructions, implemented by sp_head::opt_mark(uint ip), was recursive in some cases (a conditional jump pointing forward to another conditional jump). In case of specially crafted code, like - a long list of "IF expr THEN stmt END IF" - a long CASE statement this would actually cause a server crash with a stack overflow. In general, having a stack that grows proportionally with user data (the SQL code given by the client in a CREATE PROCEDURE) is to be avoided. In debug builds only, creating a SP / SF / Trigger which had a significant amount of code would spend --literally-- several minutes in sp_head::create, because of the debug code involved with DBUG_PRINT("info", ("Code %s ... There are several issues with this code: - in a CASE with 5 000 WHEN, there are 15 000 instructions generated, which create a sting representation of the code which is 500 000 bytes long, - using a String instead of an io stream causes performances to degrade to a total server freeze, as time is spent doing realloc of a buffer always too short, - Printing a 500 000 long string in the debug log is too verbose, - Generating this string even when DBUG_PRINT is off is useless, - Having code that potentially can affect the server behavior, used with #ifdef / #endif is useful in some cases, but is also a bad practice. After this change ================= "Case Expressions" (both simple and searched) have been simplified to not use LEX::when_list, which has been removed. Considering all the issues affecting case statements, the grammar for these has been totally re written. The existing actions, used to generate "assembly" sp_inst* code, have been preserved but moved in the new grammar, with the following changes: a) Bison rules are no longer shared between "Simple" and "Searched" case statements, because a stack instead of a flag is required to handle them. Nested statements are handled naturally by the parser stack, which by definition uses the correct rule in the correct context. Nested statements of the opposite type (simple vs searched) works correctly. The flag sp_head::IN_SIMPLE_CASE is no longer used. This is a step towards resolution of WL#2999, which correctly identified that temporary parsing flags do not belong to sp_head. The code in the action is shared by mean of the case_stmt_action_xxx() helpers. b) The backpatch mechanism, used to resolve forward jumps in the generated code, has been changed to: - create a label for the instruction following 'END CASE', - register each jump at the end of a "WHEN expr THEN stmt" in a unique backpatch list associated with the 'END CASE' label - resolve all the forward jumps for this label at once. In addition, the code involving backpatch has been commented, so that a reader can now understand by reading matching "Registering" and "Resolving" comments how the forward jumps are resolved and what target they resolve to, as this is far from evident when reading the code alone. The implementation of sp_head::opt_mark() has been revised to avoid recursive calls from jump instructions, and instead add the jump location to the list of paths to explore during the flow analysis of the instruction graph, with a call to sp_head::add_mark_lead(). In addition, the flow analysis will stop if an instruction has already been marked as reachable, which the previous code failed to do in the recursive case. sp_head::opt_mark() is now private, to prevent new calls to this method from being introduced. The debug code present in sp_head::create() has been removed. Considering that SHOW PROCEDURE CODE is also available in debug builds, and can be used anytime regardless of the trace level, as opposed to "CREATE PROCEDURE" time and only if the trace was on, removing the code actually makes debugging easier (usable trace). Tests have been written to cover the parser overflow (big CASE), and to cover nested CASE statements.	19 years ago
kroki/tomash@mysql.com/moonlight.intranet	a81c1b27e5	Bug#19207: Final parenthesis omitted for CREATE INDEX in Stored Procedure Wrong criteria was used to distinguish the case when there was no lookahead performed in the parser. Bug affected only statements ending in one-character token without any optional tail, like CREATE INDEX and CALL.	20 years ago
pem@mysql.com	67f34be961	Post-review fix for BUG#15737 (corrected typo in sp-code.test comment)	20 years ago
pem@mysql.com	f60a763208	Fixed BUG#15737: Stored procedure optimizer bug with LEAVE Second version. The problem was that the optimizer didn't work correctly with forwards jumps to "no-op" hpop and cpop instructions. Don't generate "no-op" instructions (hpop 0 and cpop 0), it isn't actually necessary.	20 years ago
pem@mysql.com	4513ffd109	Removed forgotten test line in sp-code.test.	20 years ago
pem@mysql.com	3a832faafe	Post-review fixes, mainly fixing all print() methods for sp_instr* classes. Also added mysql-test files: include/is_debug_build.inc r/is_debug_build.require r/sp-code.result t/sp-code.test	20 years ago

16 Commits (b2f8005094a661e53fce2fc670d1d1cbc096da04)