Field_time::get_time() did not initialize some members of 
MYSQL_TIME which led to valgrind warnings when those members 
were accessed in Protocol_simple::store_time(). 
 
It is unlikely that this bug could result in wrong data 
being returned, since Field_time::get_time() initializes the 
'day' member of MYSQL_TIME to 0, so the value of 'day' 
in Protocol_simple::store_time() would be 0 regardless 
of the values for 'year' and 'month'.

In UNION if we use last SELECT without braces and this
SELECT have ORDER BY clause, such clause belongs to
global UNION. It is parsed like last SELECT
part and used further as 'unit->global_parameters->order_list' value.
During DESCRIBE EXTENDED we call select_lex->print_order() for
last SELECT where order fields refer to tmp table 
which already freed. It leads to crash.
The fix is clean up global_parameters->order_list
instead of fake_select_lex->order_list.

  UNIX sockets need to be on a path shorter than 70 characters on some older platofrms.
  MTRv1 tries to fix this by moving the socket to the $TMPDIR, however this causes
  issues with certain tests on Windows.

  Fixed by not applying any hacks on Windows - Windows does not need them.

UNIX sockets need to be on a path shorter than 70 characters on some older platofrms.
MTRv1 tries to fix this by moving the socket to the $TMPDIR, however this causes
issues with certain tests on Windows.

Fixed by not applying any hacks on Windows - Windows does not need them.

with appropriate condition.

Problem: using LOAD_FILE() in some cases we pass a file name string
without a trailing '\0' to fn_format() which relies on that however.
That may lead to valgrind warnings.

Fix: add a trailing '\0' to the file name passed to fn_format().

Also, add CPP so Windows works properly for profiling. Community-server
functionality is required.

Problem: storing "SELECT ... INTO @var ..." results in variables we used val_xxx()
methods which returned results of the current row. 
So, in some cases (e.g. SELECT DISTINCT, GROUP BY or HAVING) we got data
from the first row of a new group (where we evaluate a clause) instead of
data from the last row of the previous group.

Fix: use val_xxx_result() counterparts to get proper results.

backwards, which resulted in the incorrect time being reported at the
end of mysqldump. (Bug #44424, patch by Andrew Hutchings)

which didn't actually do anything. (Bug #39101)

  
The --hexdump option crashed mysqlbinlog when used together  
with the --read-from-remote-server option due to use of  
uninitialized memory.  
  
Since Log_event::print_header() relies on temp_buf to be  
initialized when the --hexdump option is present,  
dump_remote_log_entries() was fixed to setup temp_buf to point  
to the start of a binlog event as done in  
dump_local_log_entries().  
 
The root cause of this bug is identical to the one for 
bug #17654. The latter was fixed in 5.1 and up, so this 
patch is backport of the patches for bug #17654 to 5.0. 
 
Only 5.0 needs a changelog entry. 

adventure.

         with seg fault

Multiple-table DELETE from a table joined to itself may cause
server crash. This was originally discovered with MEMORY engine,
but may affect other engines with different symptoms.

The problem was that the server violated SE API by performing
parallel table scan in one handler and removing records in
another (delete on the fly optimization).

EXPLAIN EXTENDED of nested query containing a error:

   1054 Unknown column '...' in 'field list'

may cause a server crash.


Parse error like described above forces a call to
JOIN::destroy() on malformed subquery.
That JOIN::destroy function closes and frees temporary
tables. However, temporary fields of these tables
may be listed in st_select_lex::group_list of outer
query, and that st_select_lex may not cleanup them
properly. So, after the JOIN::destroy call that
st_select_lex::group_list may have Item_field
objects with dangling pointers to freed temporary
table Field objects. That caused a crash.

into actual tree

per-file comments:
  tests/mysql_client_test.c
the test for bug 37956 isn't relevant anymore.
The query there 'select point(?,?)' doesn't produce an error.