Commit graph

25 commits

Author SHA1 Message Date
Alexey Kopytov
df389d0135 Bug#55077: Assertion failed: width > 0 && to != ((void *)0),
file .\dtoa.c

The assertion failure was correct because the 'width' argument
of my_gcvt() has the signed integer type, whereas the unsigned
value UINT_MAX32 was being passed by the caller
(Field_double::val_str()) leading to a negative width in
my_gcvt().

The following chain of problems was found by further analysis:

1. The display width for a floating point number is calculated
in Field_double::val_str() as either field_length or the
maximum possible length of string representation of a floating
point number, whichever is greater. Since in the bug's test
case field_length is UINT_MAX32, we get the same value as the
display width. This does not make any sense because for numeric
values field_length only matters for ZEROFILL columns,
otherwise it does not make sense to allocate that much memory
just to print a number. Field_float::val_str() has a similar
problem.

2. Even if the above wasn't the case, we would still get a
crash on a slightly different test case when trying to allocate
UINT_MAX32 bytes with String::alloc() because the latter does
not handle such large input values correctly due to alignment
overflows.

3. Even when String::alloc() is fixed to return an error when
an alignment overflow occurs, there is still a problem because
almost no callers check its return value, and
Field_double::val_str() is not an exception (same for
Field_float::val_str()).

4. Even if all of the above wasn't the case, creating a
Field_double object with UINT_MAX32 as its field_length does
not make much sense either, since the .frm code limits it to
MAX_FIELD_CHARLENGTH (255) bytes. Such a beast can only be
created by create_tmp_field_from_item() from an Item with
REAL_RESULT as its result_type() and UINT_MAX32 as its
max_length.

5. For the bug's test case, the above condition (REAL_RESULT
Item with max_length = UINT_MAX32) was a result of
Item_func_if::fix_length_and_dec() "shortcutting" aggregation
of argument types when one of the arguments was a constant
NULL. In this case, the attributes of the aggregated type were
simply copied from the other, non-NULL argument, but max_length
was still calculated as per the general, non-shortcut case, by
choosing the greatest of argument's max_length, which is
obviously not correct.

The patch addresses all of the above problems, even though
fixing the assertion failure for the particular test case would
require only a subset of the above problems to be solved.
2010-08-25 19:57:53 +04:00
Gleb Shchepa
c1bf0475cf Bug : Assert on sum function on
IF(..., CAST(longtext AS UNSIGNED), signed_val)
            (was: LEFT JOIN on inline view crashes server)

Select from a LONGTEXT column wrapped with an expression
like "IF(..., CAST(longtext_column AS UNSIGNED), smth_signed)"
failed an assertion or crashed the server. IFNULL function was
affected too.

LONGTEXT column item has a maximum length of 32^2-1 bytes,
at the same time this is a maximum possible length of any
MySQL item. CAST(longtext_column AS UNSIGNED) returns some
unsigned numeric result of length 32^2-1, so the result of
IF/IFNULL function of this number and some other signed number
will have text length of (32^2-1)+1=32^2 (one byte for the
minus sign) - there is integer overflow, and the length is
equal to zero. That caused assert/crash.

CAST AS UNSIGNED function has been modified to limit maximal
length of resulting number to 67 (maximal length of DECIMAL
and two characters for minus sign and dot).
2008-12-12 17:16:25 +04:00
Gleb Shchepa
03f9b2cea6 rollback of bug fix 2008-12-12 14:59:10 +04:00
Gleb Shchepa
ce8ad64dd2 Bug : Assert on sum function on
IF(..., CAST(longtext AS UNSIGNED), signed_val)
            (was: LEFT JOIN on inline view crashes server)

Select from a LONGTEXT column wrapped with an expression
like "IF(..., CAST(longtext_column AS UNSIGNED), smth_signed)"
failed an assertion or crashed the server. IFNULL function was
affected too.

LONGTEXT column item has a maximum length of 32^2-1 bytes,
at the same time this is a maximum possible length of any
MySQL item. CAST(longtext_column AS UNSIGNED) returns some
unsigned numeric result of length 32^2-1, so the result of
IF/IFNULL function of this number and some other signed number
will have text length of (32^2-1)+1=32^2 (one byte for the
minus sign) - there is integer overflow, and the length is
equal to zero. That caused assert/crash.

The bug has been fixed by the same solution as in the CASE
function implementation.
2008-12-12 00:57:32 +04:00
Georgi Kodinov
425abb4904 Bug#37662 nested if() inside sum() is parsed in exponential time
min() and max() functions are implemented in MySQL as macros.
This means that max(a,b) is expanded to: ((a) > (b) ? (a) : (b))
Note how 'a' is quoted two times.
Now imagine 'a' is a recursive function call that's several 10s of levels deep.
And the recursive function does max() with a function arg as well to dive into
recursion.
This means that simple function call can take most of the clock time.
Identified and fixed several such calls to max()/min() : including the IF() 
sql function implementation.
2008-07-30 14:07:37 +03:00
malff/marcsql@weblab.(none)
4e556b2305 Bug#24532 (The return data type of IS TRUE is different from similar
operations)

Before this change, the boolean predicates:
- X IS TRUE,
- X IS NOT TRUE,
- X IS FALSE,
- X IS NOT FALSE
were implemented by expanding the Item tree in the parser, by using a
construct like:
Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>)

Each <value> was a constant integer, either 0 or 1.

A bug in the implementation of the function IF(a, b, c), in
Item_func_if::fix_length_and_dec(), would cause the following :

When the arguments b and c are both unsigned, the result type of the
function was signed, instead of unsigned.

When the result of the if function is signed, space for the sign could be
counted twice (in the max() expression for a signed argument, and in the
total), causing the member max_length to be too high.

An effect of this is that the final type of IF(x, int(1), int(1)) would be
int(2) instead of int(1).

With this fix, the problems found in Item_func_if::fix_length_and_dec()
have been fixed.

While it's semantically correct to represent 'X IS TRUE' with
Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>),
there are however more problems with this construct.

a)
Building the parse tree involves :
- creating 5 Item instances (3 ints, 1 ifnull, 1 if),
- creating each Item calls my_pthread_getspecific_ptr() once in the operator
  new(size), and a second time in the Item::Item() constructor, resulting
  in a total of 10 calls to get the current thread.
Evaluating the expression involves evaluating up to 4 nodes at runtime.
This representation could be greatly simplified and improved.

b)
Transforming the parse tree internally with if(ifnull(...)) is fine as long
as this transformation is internal to the server implementation.
With views however, the result of the parse tree is later exposed by the
::print() functions, and stored as part of the view definition.
Doing this has long term consequences:

1)
The original semantic 'X IS TRUE' is lost, and replaced by the
if(ifnull(...)) expression. As a result, SHOW CREATE VIEW does not restore
the original code.

2)
Should a future version of MySQL implement the SQL BOOLEAN data type for
example, views created today using 'X IS NULL' can be exported using
mysqldump, and imported again. Such views would be converted correctly and
automatically to use a BOOLEAN column in the future version.
With 'X IS TRUE' and the current implementations, views using these
"boolean" predicates would not be converted during the export/import, and
would use integer columns instead.
The difference traces back to how SHOW CREATE VIEW preserves 'X IS NULL' but
does not preserve the 'X IS TRUE' semantic.

With this fix, internal representation of 'X IS TRUE' booleans predicates
has changed, so that:
- dedicated Item classes are created for each predicate,
- only 1 Item is created to represent 1 predicate
- my_pthread_getspecific_ptr() is invoked 1 time instead of 10
- SHOW CREATE VIEW preserves the original semantic, and prints 'X IS TRUE'.

Note that, because of the fix in Item_func_if, views created before this fix
will:
- correctly use a int(1) type instead of int(2) for boolean predicates,
- incorrectly print the if(ifnull(...), ...) expression in SHOW CREATE VIEW,
since the original semantic (X IS TRUE) has been lost.
- except for the syntax used in SHOW CREATE VIEW, these views will operate
properly, no action is needed.

Views created after this fix will operate correctly, and will preserve the
original code semantic in SHOW CREATE VIEW.
2007-02-12 13:59:29 -07:00
evgen@moonbone.local
8f904e9cab Fixed bug#16272: IF function with decimal args can produce wrong result
The Item_func_if::fix_length_and_dec() function when calculating length of 
result doesn't take into account unsigned_flag. But it is taken when 
calculating length of temporary field. This result in creating field that 
shorter than needed. Due to this, in the reported query 40.0 converted to 9.99.

The function Item_func_if::fix_length_and_dec() now adds 1 to the max_length if 
the unsigned_flag isn't set.
2006-02-14 16:22:37 +03:00
monty@mysql.com
15d48525af Merge mysql.com:/home/my/mysql-4.1
into  mysql.com:/home/my/mysql-5.0
2005-07-28 17:09:54 +03:00
monty@mysql.com
3c12d0ae54 Added end marker for tests to make future merges easier 2005-07-28 03:22:47 +03:00
ndbdev@dl145b.mysql.com
be1177c15b merge 2005-06-14 00:05:27 +02:00
igor@igor-inspiron.creware.com
754e6c0527 func_if.result, func_if.test:
Correction for test case of bug .
2005-06-13 11:38:16 -07:00
igor@igor-inspiron.creware.com
42271e4240 func_if.result, func_if.test:
Added a test case for bug .
item_cmpfunc.cc:
  Fixed bug .
  Implementation of Item_func_nullif::is_null was corrected.
2005-06-13 11:24:26 -07:00
evgen@moonbone.local
f89352602c Fix bug Ordering on IF function with FROM_UNIXTIME function fails
Integer overflow results in wrong field sortlength.
2005-06-02 17:00:07 +04:00
monty@mysql.com
201ee3eb78 Invalid DEFAULT values for CREATE TABLE now generates errors. (Bug )
CAST() now produces warnings when casting a wrong INTEGER or CHAR values. This also applies to implicite string to number casts. (Bug )
ALTER TABLE now fails in STRICT mode if it generates warnings.
Inserting a zero date in a DATE, DATETIME or TIMESTAMP column during TRADITIONAL mode now produces an error. (Bug )
2005-04-01 15:04:50 +03:00
monty@mysql.com
62f3cd6a31 Merge with 4.0 for 4.1 release
Noteworthy:
- New HANDLER code
- New multi-update-grant-check code
- Table lock code in ha_innodb.cc was not applied
2004-10-06 19:14:33 +03:00
gluh@gluh.mysql.r18.ru
276622c92d Fix for bug : NULLIF() IS NULL returns false if NULLIF() returns NULL 2004-09-18 13:06:44 +04:00
monty@mysql.com
b11d258835 Merge with 4.0.21 2004-06-18 04:38:58 +03:00
serg@serg.mylan
86e9dc29b0 BUG#3987 - if(int, aggregate(int)) 2004-06-07 12:38:35 +02:00
monty@mysql.com
f9ad650490 merge with 4.0 2004-03-17 10:36:12 +02:00
gluh@gluh.mysql.r18.ru
86211a1b44 Fix for bug NULLIF() doesn't behave as described in manual 2004-03-16 11:33:03 +04:00
antony@ltantony.rdg.cyberkinetica.homeunix.net
fcf96dbb18 WorkLog#1323
Deprecate the use of TYPE=... Preferred syntax is ENGINE=
2003-12-10 04:31:42 +00:00
bell@sanja.is.com.ua
33346e26af added code covarage for functions convert(), nullif(), crc32(), is_used_lock(), char_lengtrh(), bit_xor()
added string length for more speed
made code covarage for print() method of Item
fixed printability of some items (SCRUM) (WL#1274)
2003-10-30 12:57:26 +02:00
monty@mashka.mysql.fi
1f6ecc0cd3 Changed mysql-test to print warnings for not existing table to DROP TABLE
Cleaned up test; Removed wrong DROP TABLE commands and use standard table and database names.
changed store_warning() -> push_warning_print()
2003-01-06 01:48:59 +02:00
Sinisa@sinisa.nasamreza.org
a80d185e40 A change in IF behaviour that several users asked for ... 2002-08-09 23:14:02 +03:00
monty@tik.mysql.fi
ecf2c4e15a New if tests 2002-04-22 23:41:55 +03:00