lp:~knielsen/maria/mysql-5.1.50-libmysqld.so

Branch merges

Propose for merging

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

3473. By Kristian Nielsen on 2010-09-24

Port MariaDB libmysqld.so patch to MySQL 5.1.50.

3472. By Alfranio Correia on 2010-08-03

auto-merge mysql-5.1-security (local) --> mysql-5.1-security

3471. By Georgi Kodinov on 2010-08-02

merge

3470. By Georgi Kodinov on 2010-08-02

merge mysql-5.1-bugteam into mysql-5.1-security

3469. By Gleb Shchepa <email address hidden> on 2010-08-01

Bug #54461: crash with longblob and union or update with subquery

Queries may crash, if
  1) the GREATEST or the LEAST function has a mixed list of
     numeric and LONGBLOB arguments and
  2) the result of such a function goes through an intermediate
     temporary table.

An Item that references a LONGBLOB field has max_length of
UINT_MAX32 == (2^32 - 1).

The current implementation of GREATEST/LEAST returns REAL
result for a mixed list of numeric and string arguments (that
contradicts with the current documentation, this contradiction
was discussed and it was decided to update the documentation).

The max_length of such a function call was calculated as a
maximum of argument max_length values (i.e. UINT_MAX32).

That max_length value of UINT_MAX32 was used as a length for
the intermediate temporary table Field_double to hold
GREATEST/LEAST function result.

The Field_double::val_str() method call on that field
allocates a String value.

Since an allocation of String reserves an additional byte
for a zero-termination, the size of String buffer was
set to (UINT_MAX32 + 1), that caused an integer overflow:
actually, an empty buffer of size 0 was allocated.

An initialization of the "first" byte of that zero-size
buffer with '\0' caused a crash.

The Item_func_min_max::fix_length_and_dec() has been
modified to calculate max_length for the REAL result like
we do it for arithmetical operators.

******
Bug #54461: crash with longblob and union or update with subquery

Queries may crash, if
  1) the GREATEST or the LEAST function has a mixed list of
     numeric and LONGBLOB arguments and
  2) the result of such a function goes through an intermediate
     temporary table.

An Item that references a LONGBLOB field has max_length of
UINT_MAX32 == (2^32 - 1).

The current implementation of GREATEST/LEAST returns REAL
result for a mixed list of numeric and string arguments (that
contradicts with the current documentation, this contradiction
was discussed and it was decided to update the documentation).

The max_length of such a function call was calculated as a
maximum of argument max_length values (i.e. UINT_MAX32).

That max_length value of UINT_MAX32 was used as a length for
the intermediate temporary table Field_double to hold
GREATEST/LEAST function result.

The Field_double::val_str() method call on that field
allocates a String value.

Since an allocation of String reserves an additional byte
for a zero-termination, the size of String buffer was
set to (UINT_MAX32 + 1), that caused an integer overflow:
actually, an empty buffer of size 0 was allocated.

An initialization of the "first" byte of that zero-size
buffer with '\0' caused a crash.

The Item_func_min_max::fix_length_and_dec() has been
modified to calculate max_length for the REAL result like
we do it for arithmetical operators.

3468. By Alexey Kopytov on 2010-07-23

Bug #54476: crash when group_concat and 'with rollup' in
                     prepared statements

Using GROUP_CONCAT() together with the WITH ROLLUP modifier
could crash the server.

The reason was a combination of several facts:

1. The Item_func_group_concat class stores pointers to ORDER
objects representing the columns in the ORDER BY clause of
GROUP_CONCAT().

2. find_order_in_list() called from
Item_func_group_concat::setup() modifies the ORDER objects so
that their 'item' member points to the arguments list
allocated in the Item_func_group_concat constructor.

3. In some cases (e.g. in JOIN::rollup_make_fields) a copy of
the original Item_func_group_concat object could be created by
using the Item_func_group_concat::Item_func_group_concat(THD
*thd, Item_func_group_concat *item) copy constructor. The
latter essentially creates a shallow copy of the source
object. Memory for the arguments array is allocated on
thd->mem_root, but the pointers for arguments and ORDER are
copied verbatim.

What happens in the test case is that when executing the query
for the first time, after a copy of the original
Item_func_group_concat object has been created by
JOIN::rollup_make_fields(), find_order_in_list() is called for
this new object. It then resolves ORDER BY by modifying the
ORDER objects so that they point to elements of the arguments
array which is local to the cloned object. When thd->mem_root
is freed upon completing the execution, pointers in the ORDER
objects become invalid. Those ORDER objects, however, are also
shared with the original Item_func_group_concat object which is
preserved between executions of a prepared statement. So the
first call to find_order_in_list() for the original object on
the second execution tries to dereference an invalid pointer.

The solution is to create copies of the ORDER objects when
copying Item_func_group_concat to not leave any stale pointers
in other instances with different lifecycles.

3467. By Georgi Kodinov on 2010-07-21

merge

3466. By Georgi Kodinov on 2010-07-21

merge

3465. By Georgi Kodinov on 2010-07-21

merge

3464. By jimmy on 2010-07-09

Fix bug #55039 Failing assertion: space_id > 0 in fil0fil.c.

rb://396, approved by Sunny Bains.