Commit graph

382 commits

Author SHA1 Message Date
Kristofer Pettersson
18b3eacbc6 Bug#38469 invalid memory read and/or crash with utf8 text field, stored procedure, uservar
A stored procedure involving substrings could crash the server on certain
platforms because of invalid memory reads.
          
During storing the new blob-field value, the cached value's address range
overlapped that of the new field value. This caused problems when the 
cached value storage was reallocated to provide access for a new 
characater set representation. The patch checks the address ranges, and if
they overlap, the new field value is copied to a new storage before it is
converted to the new character set.
2008-09-20 10:51:03 +02:00
Sergey Glukhov
9bc9ddd56e Bug#38291 memory corruption and server crash with view/sp/function
Send_field.org_col_name has broken value on secondary execution.
It happens when result field is created from the field which belongs to view
due to forgotten assignment of some Send_field attributes. 
The fix:
set Send_field.org_col_name,org_table_name with correct value during Send_field intialization.
2008-08-20 14:49:28 +05:00
kaa@kaamos.(none)
3daeb40f1f Merge kaamos.(none):/data/src/mysql-5.0
into  kaamos.(none):/data/src/opt/mysql-5.0-opt
2008-02-17 14:37:39 +03:00
evgen@moonbone.local
f967e24718 Bug#30787: Stored function ignores user defined alias.
Simple subselects are pulled into upper selects. This operation substitutes the
pulled subselect for the first item from the select list of the subselect.
If an alias is defined for a subselect it is inherited by the replacement item.
As this is done after fix_fields phase this alias isn't showed if the
replacement item is a stored function. This happens because the Item_func_sp::make_field
function makes send field from its result_field and ignores the defined alias.

Now when an alias is defined the Item_func_sp::make_field function sets it for
the returned field.
2008-01-31 23:46:26 +03:00
malff@lambda.hsd1.co.comcast.net.
1eecc24a21 Merge malff@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime
into  lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.0-33618
2008-01-23 14:04:46 -07:00
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.
2008-01-23 13:26:41 -07:00
davi@mysql.com/endora.local
025aadce8a Bug#29770 Two handlers are allowed to catch an error in an stored procedure.
Add test case.
2008-01-08 18:43:25 -02:00
malff@lambda.hsd1.co.comcast.net.
a9c6ed46e2 Implementing code review comments 2007-10-16 11:16:31 -06:00
anozdrin/alik@station.
05cf10bdf6 Cleanup sp.test. 2007-10-10 14:42:29 +04:00
kostja@bodhi.(none)
7ec30183bb Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  bodhi.(none):/opt/local/work/mysql-5.0-runtime
2007-10-08 02:05:55 +04:00
anozdrin/alik@station.
707f067446 Fix for BUG#31035: select from function, group by result crasher.
This actually, fix for the patch for bug-27354. The problem with
the patch was that Item_func_sp::used_tables() was updated, but
Item_func_sp::const_item() was not. So, for Item_func_sp, we had
the following inconsistency:
  - used_tables() returned RAND_TABLE, which means that the item
    can produce "random" results;
  - but const_item() returned TRUE, which means that the item is
    a constant one.

The fix is to change Item_func_sp::const_item() behaviour: it must
return TRUE (an item is a constant one) only if a stored function
is deterministic and each of its arguments (if any) is a constant
item.
2007-10-04 17:19:14 +04:00
gshchepa/uchum@gleb.loc
ff042427cf Merge gleb.loc:/home/uchum/work/bk/5.0
into  gleb.loc:/home/uchum/work/bk/5.0-opt
2007-09-12 23:41:35 +05:00
gshchepa/uchum@gleb.loc
d330a49105 Merge gleb.loc:/home/uchum/work/bk/5.0
into  gleb.loc:/home/uchum/work/bk/5.0-opt
2007-09-06 22:27:13 +05:00
malff/marcsql@weblab.(none)
3a7bcd72f3 Merge weblab.(none):/home/marcsql/TREE/mysql-5.0-base
into  weblab.(none):/home/marcsql/TREE/mysql-5.0-rt-merge
2007-09-04 14:38:26 -06:00
gluh@mysql.com/eagle.(none)
33eaf2cd95 Bug#29408 Cannot find view in columns table if the selection contains a function
Use view db name as thread default database, in order to ensure
that the view is parsed and prepared correctly.
2007-09-03 12:22:56 +05:00
anozdrin/alik@ibm.
290d724943 Test case for Bug#13675: DATETIME/DATE type in store proc param
seems to be converted as varbinary.

The bug has been already fixed. This CS just adds a test case for it.
2007-08-29 14:57:59 +04:00
msvensson@pilot.(none)
2258a423b2 Merge 192.168.0.7:mysql/mysql-5.0-maint
into  pilot.(none):/data/msvensson/mysql/mysql-5.0-maint
2007-08-03 12:57:09 +02:00
msvensson@shellback.(none)
d6f02500af Cleanup created procedures in sp.test 2007-08-03 12:56:45 +02:00
gshchepa/uchum@gleb.loc
1eb20fc0a5 Fixed bug #30120.
SP with local variables with non-ASCII names crashed the server.

The server replaces SP local variable names with NAME_CONST calls
when putting statements into the binary log. It used UTF8-encoded
item names as variable names for the replacement inside NAME_CONST
calls. However, statement string may be encoded by any
known character set by the SET NAMES statement.
The server used byte length of UTF8-encoded names to increment
the position in the query string that led to array index overrun.
2007-07-30 04:35:16 +05:00
gshchepa/uchum@gleb.loc
a077dd8f61 Merge gleb.loc:/home/uchum/work/bk/5.0-opt-29834
into  gleb.loc:/home/uchum/work/bk/5.0-opt
2007-07-28 23:36:27 +05:00
gshchepa/uchum@gleb.loc
ff5d72021e Fixed bug #29834.
Using view columns by their names during an execution of
a prepared SELECT statement or a SELECT statement inside
a SP caused a memory leak.
2007-07-28 23:10:38 +05:00
gshchepa/uchum@gleb.loc
882bb64fc6 Merge gleb.loc:/home/uchum/work/bk/5.0-opt-29338
into  gleb.loc:/home/uchum/work/bk/5.0-opt
2007-07-22 01:52:13 +05:00
gshchepa/uchum@gleb.loc
872d21eb1f sp.test, sp.result:
Additional test case fix for bug #29338.
2007-07-22 01:49:41 +05:00
gshchepa/uchum@gleb.loc
2313bbc304 Merge gleb.loc:/home/uchum/work/bk/5.0-opt-29338
into  gleb.loc:/home/uchum/work/bk/5.0-opt
2007-07-22 00:40:14 +05:00
gshchepa/uchum@gleb.loc
73b2848f4f Fixed bug #29338.
Optimization of queries with DETERMINISTIC functions in the
WHERE clause was not effective: sequential scan was always
used.
Now a SF with the DETERMINISTIC flags is treated as constant
when it's arguments are constants (or a SF doesn't has arguments).
2007-07-19 18:39:01 +05:00
kostja@bodhi.(none)
7989c712a6 Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  bodhi.(none):/opt/local/work/mysql-5.0-runtime
2007-07-16 23:41:28 +04:00
kostja@bodhi.(none)
a7b05cb786 A fix and a test case for Bug#29050 Creation of a legal stored procedure
fails if a database is not selected prior.

The problem manifested itself when a user tried to
create a routine that had non-fully-qualified identifiers in its bodies
and there was no current database selected.

This is a regression introduced by the fix for Bug 19022:

The patch for Bug 19022 changes the code to always produce a warning
if we can't resolve the current database in the parser. 
In this case this was not necessary, since even though the produced
parsed tree was incorrect, we never re-use sphead
that was obtained at first parsing of CREATE PROCEDURE.
The sphead that is anyhow used is always obtained through db_load_routine,
and there we change the current database to sphead->m_db before
calling yyparse.

The idea of the fix is to resolve the current database directly using 
lex->sphead->m_db member when parsing a stored routine body, when
such is present.

This patch removes the need to reset the current database
when loading a trigger or routine definition into SP cache.
The redundant code will be removed in 5.1.
2007-07-05 11:34:04 +04:00
kostja@bodhi.(none)
c3f37e0b3d A fix and a teset case for Bug#28551 The warning
'No database selected' is reported when calling stored procedures

Remove the offending warning introduced by the fix for Bug
25082
This minimal patch relies on the intrinsic knowledge of the fact that
mysql_change_db is never called with 'force_switch' set to TRUE
when such a warning may be needed:
 * every stored routine belongs to a database (unlike, e.g., a 
user defined function, which does not), so if we're activating the
database of a stored routine, it can never be NULL.
Therefore, this branch is never called for activation.
 * if we're restoring the 'old' current database after routine
execution is complete, we should not issue a warning, since it's OK to 
call a routine without having previously selected the current database.

TODO: 'force_switch' is an ambiguous flag, since we do not actually
have to 'force' the switch in case of stored routines at all.
When we activate the routine's database, we should perform
all the checks as in case of 'use db', and so we already do (in this
case 'force_switch' is unused).
When we load a routine into cache, we should not use mysql_change_db
at all, since there it's enough to call thd->reset_db(). We
do it this way for triggers, but code for routines is different (wrongly). 

TODO: bugs are lurking in replication, since it bypasses mysql_change_db
and calls thd->[re_]set_db to set the current database.
The latter does not change thd->db_charset, thd->sctx->db_access
and thd->variables.collation_database (and this may have nasty side
effects).

These todo items are to be addressed in a separate patch, if at all.
2007-07-05 02:20:32 +04:00
msvensson@pilot.(none)
781bc31263 Merge pilot.(none):/data/msvensson/mysql/bug28356/my50-bug28356
into  pilot.(none):/data/msvensson/mysql/mysql-5.0-maint
2007-06-29 10:27:21 +02:00
msvensson@pilot.(none)
b9d2e744b0 Change "exec rm" to "remove_file" 2007-06-27 18:21:20 +02:00
ibabaev@bk-internal.mysql.com
4bc1738be0 Merge bk-internal.mysql.com:/data0/bk/mysql-5.0
into  bk-internal.mysql.com:/data0/bk/mysql-5.0-opt
2007-06-02 00:57:25 +02:00
kostja@bodhi.(none)
d97db648a0 Fix some mysqltest warnings. 2007-06-01 17:49:01 +04:00
gkodinov/kgeorge@magare.gmz
a6ebd63479 Bug #28605: SHOW CREATE VIEW with views using stored_procedures no
longer showing SP names.
SHOW CREATE VIEW uses Item::print() methods to reconstruct the 
statement text from the parse tree.
The print() method for stored procedure calls needs allocate 
space to print the function's quoted name.
It was incorrectly calculating the length of the buffer needed 
(was too short).
Fixed to reflect the actual space needed.
2007-05-29 14:45:30 +03:00
malff/marcsql@weblab.(none)
4b0d37362b Merge weblab.(none):/home/marcsql/TREE/mysql-5.0-base
into  weblab.(none):/home/marcsql/TREE/mysql-5.0-rt-merge
2007-05-02 09:59:39 -06:00
malff/marcsql@weblab.(none)
012f841fd4 Bug#21513 (SP having body starting with quoted label rendered unusable)
Before this fix, the parser would sometime change where a token starts by
altering Lex_input_string::tok_start, which later confused the code in
sql_yacc.yy that needs to capture the source code of a SQL statement,
like to represent the body of a stored procedure.

This line of code in sql_lex.cc :

case MY_LEX_USER_VARIABLE_DELIMITER:
  lip->tok_start= lip->ptr; // Skip first `

would <skip the first back quote> ... and cause the bug reported.

In general, the responsibility of sql_lex.cc is to *find* where token are
in the SQL text, but is *not* to make up fake or incomplete tokens.
With a quoted label like `my_label`, the token starts on the first quote.
Extracting the token value should not change that (it did).

With this fix, the lexical analysis has been cleaned up to not change
lip->tok_start (in the case found for this bug).

The functions get_token() and get_quoted_token() now have an extra
parameters, used when some characters from the beginning of the token need
to be skipped when extracting a token value, like when extracting 'AB' from
'0xAB', for example, for a HEX_NUM token.

This exposed a bad assumption in Item_hex_string and Item_bin_string,
which has been fixed:

The assumption was that the string given, 'AB', was in fact preceded in
memory by '0x', which might be false (it can be preceded by "x'" and
followed by "'" -- or not be preceded by valid memory at all)

If a name is needed for Item_hex_string or Item_bin_string, the name is
taken from the original and true source code ('0xAB'), and assigned in
the select_item rule, instead of relying on assumptions related to how
memory is used.
2007-04-27 17:14:25 -06:00
df@pippilotta.erinye.com
e0f148d5f0 Fix test case that was broken for builds without InnoDB. 2007-04-25 20:23:19 +02:00
malff/marcsql@weblab.(none)
fc36313733 Merge weblab.(none):/home/marcsql/TREE/mysql-5.0-base
into  weblab.(none):/home/marcsql/TREE/mysql-5.0-rt-merge
2007-04-20 15:34:04 -06:00
anozdrin/alik@ibm.
9719af3f2b Test case for BUG#5274: Stored procedure crash if length
of CHAR variable too great.
2007-04-12 19:42:45 +04:00
jani@ua141d10.elisa.omakaista.fi
335153121b Merge jamppa@bk-internal.mysql.com:/home/bk/mysql-5.0
into  ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-5.0-marvel
2007-04-12 12:50:02 +03:00
anozdrin/alik@alik.opbmk
cc83bb0784 Fix for BUG#25082: default database change on trigger
execution breaks replication.

When a stored routine is executed, we switch current
database to the database, in which the routine
has been created. When the stored routine finishes,
we switch back to the original database.

The problem was that if the original database does not
exist (anymore) after routine execution, we raised an error.

The fix is to report a warning, and switch to the NULL database.
2007-03-27 21:55:01 +04:00
thek@kpdesk.mysql.com
1381b26e36 Corrected error in test case:
- 1.84e+15 converted to unsigned bigint should be
  18400000000000000000 < 18446744073709551615.
- The test will still fail on windows, and is extracted
  into a new bug report.
2007-03-27 18:05:17 +02:00
serg@sergbook.mysql.com
237ed0c3e5 Merge bk-internal.mysql.com:/home/bk/mysql-5.0-marvel
into  sergbook.mysql.com:/usr/home/serg/Abk/mysql-5.0
2007-03-24 17:16:53 +02:00
Kristofer.Pettersson@naruto.
fe43de3929 Merge naruto.:C:/cpp/bug20777/my50-bug20777
into  naruto.:C:/cpp/mysql-5.0-runtime
2007-03-23 19:14:13 +01:00
aelkin/elkin@andrepl.(none)
9856be570a Bug #27354 stored function in where condition was always treated as const
Possible problems: function call could be eliminated from where class and only
be evaluated once; function can be evaluated during table and item setup phase which could
cause side effects not to be registered in binlog.

Fixed with introducing func_item_sp::used_tables() returning the correct table_map constant.
2007-03-22 19:17:15 +02:00
kostja@bodhi.local
a9065201d5 Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  bodhi.local:/opt/local/work/mysql-5.0-runtime
2007-03-19 23:59:53 +03:00
Kristofer.Pettersson@naruto.
05bef7884a Bug#20777 Function w BIGINT UNSIGNED shows diff. behaviour with and without --ps-protocol
- Stored procedures returning unsinged values returns signed values if
  text protocol is used. The reason is that the stored proceedure item
  Item_func_sp wasn't initializing the member variables properly based
  on the information contained in the associated result field.
- The patch is to upon field-item association, ::fix_fields, initialize
  the member variables in appropriate order.
- Field type of an Item_func_sp was hard coded to MYSQL_TYPE_VARCHAR.
  This is changed to return the type of the actual result field.
- Member function name sp_result_field was refactored to the more 
  appropriate init_result_field.
- Member function name find_and_check_access was refactored to 
  sp_check_access.
2007-03-16 14:25:11 +01:00
malff/marcsql@weblab.(none)
bef323b1d6 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.
2007-03-14 12:02:32 -06:00
holyfoot/hf@mysql.com/hfmain.(none)
11dd0fa326 Merge bk@192.168.21.1:mysql-5.0
into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
2007-03-08 21:42:41 +04:00
kroki/tomash@moonlight.home
1792908381 Merge moonlight.home:/home/tomash/src/mysql_ab/mysql-5.0
into  moonlight.home:/home/tomash/src/mysql_ab/mysql-5.0-bug20492
2007-03-08 15:16:21 +03:00
evgen@moonbone.local
b81b814cd1 Bug#25373: Stored functions wasn't compared correctly which leads to a wrong
result.

For built-in functions like sqrt() function names are hard-coded and can be
compared by pointer. But this isn't the case for a used-defined stored
functions - names there are dynamical and should be compared as strings.

Now the Item_func::eq() function employs my_strcasecmp() function to compare
used-defined stored functions names.
2007-03-07 22:11:57 +03:00