The reason for the bug is that mysqtest as well as other client tools
running in test suite (mysqlbinlog, mysqldump) will first try to connect 
whatever database has created shared memory with default base name 
"MySQL" and use this. (Same effect could be seen on Unix if mtr would
not care to calculate "port" and "socket" parameter).
      
The fix ensures that all client tools and  running in mtr use unique  
per-database shared memory base parameters, so there is no possibility
to clash with already installed one. We use socket name for shared memory 
base (it's known to be unique). This shared-memory-base is written to the
MTR config file to the [client] and [mysqld] sections. Fix made also made 
sure all client tools understand and correctly handle --shared-memory-base.
Prior to this patch  it was not the case for  mysqltest, mysqlbinlog and 
mysql_client_test.
      
All new connections done from mtr scripts via connect() will by default 
set shared-memory-base. And finally, there is a possibility to force 
shared memory or pipe connection and overwrite shared memory/pipe base name
from within mtr scripts via optional PIPE or SHM modifier. This functionality
was manually backported from 6.0
(original patch  http://lists.mysql.com/commits/74749)

Bug#31621: Windows server hanging during shutdown using named pipes 
           and idle connection
            
Problem: when idle pipe connection is forcefully closed with KILL
statement or when the server goes down, thread that is closing connection
would hang infinitely in CloseHandle(). The reason for the hang is that 
named pipe operations are performed synchronously. In this mode all IOs
on pipe are serialized, that is CloseHandle() will not abort ReadFile() 
in another thread, but wait for ReadFile() to complete.
            
The fix implements asynchrnous mode for named pipes, where operation of file
are not synchronized. Read/Write operation would fire an async IO and wait for
either IO completion or timeout.
            
Note, that with this patch timeouts are properly handled for named pipes.
      
Post-review: Win32 timeout code has been fixed for named pipes and shared
memory. We do not store pointer to NET in vio structure, only the read and 
write timeouts.

  subquery returning multiple rows

Error handling was missing when handling subqueires in WHERE 
and when assigning a SELECT result to a @variable.
This caused crash(es). 

Fixed by adding error handling code to both the WHERE 
condition evaluation and to assignment to an @variable.

having clause...

The fix for bug 46184 was not very complete. It was not covering
views using temporary tables and multiple tables in a FROM clause.
Fixed by reverting the fix for 46184 and making a more general
check that is checking at the right execution stage and for all
of the non-supported cases.
Now PROCEDURE ANALYZE on non-top level SELECT is also forbidden.
Updated the analyse.test and subselect.test accordingly.

Queries with nested outer joins may lead to crashes or 
bad results because an internal data structure is not handled
correctly.
The optimizer uses bitmaps of nested JOINs to determine
if certain table can be placed at a certain place in the
JOIN order.
It does maintain a bitmap describing in which JOINs 
last placed table is nested.
When it puts a table it makes sure the bit of every JOIN that
contains the table in question is set (because JOINs can be nested).
It does that by recursively setting the bit for the next enclosing
JOIN when this is the first table in the JOIN and recursively 
resetting the bit if it's the last table in the JOIN.
When it removes a table from the join order it should do the
opposite : recursively unset the bit if it's the only remaining 
table in this join and and recursively set the bit if it's removing
the last table of a JOIN.
There was an error in how the bits was set for the upper levels :
when removing a table it was setting the bit for all the enclosing 
nested JOINs even if there were more tables left in the current JOIN
(which practically means that the upper nested JOINs were not affected).
Fixed by stopping the recursion at the relevant level.

The 'rpl_get_master_version_and_clock' test verifies if the slave I/O 
thread tries to reconnect to master when it tries to get the values of 
the UNIX_TIMESTAMP, SERVER_ID from master under network disconnection. 
So the master server is restarted for making the transient network 
disconnection. Restarting master server can bring two problems as following:

1. The time out error is encountered sporadically. The slave I/O thread tries 
   to reconnect master ten times, which is set in my.cnf. So in the test 
   framework sporadically the slave I/O thread really stoped when it can't 
   reconnect to master in the ten times successfully before the master starts, 
   then the time out error will be encountered while waiting for the slave to 
   start.

2. These warnings and errors are produced in server log file when 
   the slave I/O thread tries to get the values of the UNIX_TIMESTAMP, 
   SERVER_ID from master under the transient network disconnection.

To fix problem 1, increase the master retry count to sixty times, 
so that the slave I/O thread has enough time to reconnect master 
successfully.
To fix problem 2, suppress these warnings and errors by mtr suppression, 
because they are expected.

Bug#46539 Various crashes on INSERT IGNORE SELECT + SELECT FOR UPDATE.

If a transaction was rolled back inside InnoDB due to a deadlock
or lock wait timeout, and the statement had IGNORE clause,
the server could crash at the end of the statement or on shutdown.

This was caused by the error handling infrastructure's attempt to 
ignore a non-ignorable error.

When a transaction rollback request is raised, switch off 
current_select->no_error flag, so that the following error
won't be ignored.

Instead, we could add !thd->is_fatal_sub_stmt_error to
my_message_sql(), but since in write_record() we switch
off no_error, the same approach is used in 
thd_mark_transaction_to_rollback().

@todo: call thd_mark_transaction_to_rollback() from 
handler::print_error(), then we can easily make sure
that the error reported by print_error is not ignored.

test result fix

Append the description of the 'decode-rows' value for --base64-output argument.

BUG#47073 - valgrind errs, corruption,failed repair of partition,
            low myisam_sort_buffer_size

Fixed race conditions discovered with the provided test case and
stabilized test case.

"What do you mean, there's a bug? There isn't even code!"

There was some token code for plug-in variables of the SET type,
but clearly this never worked, or was subject to massive bit rot
since. Bug-fixes ... fail-safes ... tests -- fais au mieux, mon chou!

BUG#41597 - After rename of user, there are additional grants
            when grants are reapplied.

Fixed build failure on Windows. Added missing cast.

Problem 1:
column_priv_hash uses utf8_general_ci collation
for the key comparison. The key consists of user name,
db name and table name. Thus user with privileges on table t1
is able to perform the same operation on T1
(the similar situation with user name & db name, see acl_cache).
So collation which is used for column_priv_hash and acl_cache
should be case sensitive.
The fix:
replace system_charset_info with my_charset_utf8_bin for
column_priv_hash and acl_cache
Problem 2:
The same situation with proc_priv_hash, func_priv_hash,
the only difference is that Routine name is case insensitive.
So the fix is to use my_charset_utf8_bin for
proc_priv_hash & func_priv_hash and convert routine name into lower
case before writing the element into the hash and
before looking up the key.
Additional fix: mysql.procs_priv Routine_name field collation
is changed to utf8_general_ci.
It's necessary for REVOKE command
(to find a field by routine hash element values).
Note: 
It's safe for lower-case-table-names mode too because
db name & table name are converted into lower case
(see GRANT_NAME::GRANT_NAME).