The technical problem was that THD::user_var_events_alloc was reset to NULL
from a valid value when a stored program is executed during the PREPARE statement.

The user visible problem was that the server crashed if user issued a PREPARE
statement using some combination of stored functions and user variables.

The fix is to restore THD::user_var_events_alloc to the original value.
This is a minimal fix for 5.5.

More proper patch has been already implemented for 5.6+. It avoids
evaluation of stored functions for the PREPARE phase.

From the user point of view, this bug is a regression, introduced by the patch for WL2649
(Number-to-string conversions), revid: bar@mysql.com-20100211041725-ijbox021olab82nv
However, the code resetting THD::user_var_events_alloc exists even in 5.1.
The WL just changed the way arguments are converted to strings and the bug became visible.

              TLS AND DTLS RECORD PROTOCOLS

Description: Merge from 5.1.

              TLS AND DTLS RECORD PROTOCOLS

Description: In yassl, decryption phase in TLS protocol
             depends on type of padding. This patch
             removes this dependancy and makes error
             generation/decryption process independent
             of padding type.

      
post push fix: 
rpl_stm_until.test was disabled because of
this bug. Enabled and fixed it.

Removed a part of the test that was obsolete.
It tested replication from 4.0 master to 5.0
slave.

      
post push fix: 
rpl_stm_until.test was disabled because of
this bug. Enabled and fixed it.

Removed a part of the test that was obsolete.
It tested replication from 4.0 master to 5.0
slave.

DOWNGRADED FROM 5.6.11 TO 5.6.10

Problem was new syntax not accepted by previous version.

Fixed by adding version comment of /*!50531 around the
new syntax.

Like this in the .frm file:
'PARTITION BY KEY /*!50611 ALGORITHM = 2 */ () PARTITIONS 3'
and also changing the output from SHOW CREATE TABLE to:
CREATE TABLE t1 (a INT)
/*!50100 PARTITION BY KEY */ /*!50611 ALGORITHM = 1 */ /*!50100 ()
PARTITIONS 3 */

It will always add the ALGORITHM into the .frm for KEY [sub]partitioned
tables, but for SHOW CREATE TABLE it will only add it in case it is the non
default ALGORITHM = 1.

Also notice that for 5.5, it will say /*!50531 instead of /*!50611, which
will make upgrade from 5.5 > 5.5.31 to 5.6 < 5.6.11 fail!
If one downgrades an fixed version to the same major version (5.5 or 5.6) the
bug 14521864 will be visible again, but unless the .frm is updated, it will
work again when upgrading again.

Also fixed so that the .frm does not get updated version
if a single partition check passes.

For the error code ER_TOO_LONG_IDENT, the identifier is expected in the my_error call.  So removing this line from here.  

FROM SHOW CREATE

Problem: The length of the internally generated foreign key name 
is not checked. 

Solution: The length of the internally generated foreign key name is
checked.  If it is greater than the allowed limit, an error message
is reported. Also, the constraint name is printed in the same manner
as the table name, using the system charset information.

rb://1969 approved by Marko.

Reverting back the previous changes as they are causing
issues in PB2.

Problem: Sys_vars suite is disabled in mysql-5.1 branch.
Fix: To enable sys_vars suite in mysql-5.1, add it in
mysql-test-run.pl file and also sys_vars suite should be
added to Makefile.am inorder to get that test directory

will not export internal symbols.

srv_export_innodb_status(): Read the purge_sys fields while holding
purge_sys->latch.

Approved by Sunny Bains

             5.1 SERVER

Problem was caused by the COM_CHANGE_USER parsing code. That code ignored
character set number passed in COM_CHANGE_USER packet. Instead
character_set_client values was used. User name was not converted at all.

Fixed by using passed character set number to convert both db and user names.
If COM_CHANGE_USER does not contain character set number then
character_set_client is used to convert both names.

This is a backport of the fix for:

Bug#13633549 HANDLE_FATAL_SIGNAL IN TEST_IF_SKIP_SORT_ORDER/CREATE_SORT_INDEX
Don't invoke the range optimizer for a NULL select.

SUITE FOR 5.1

SYS_VARS suite is not enabled in MTR by default
run. Enabling it with this check-in.

mysql-test/suite/sys_vars/t/disabled.def:
  Till the bugs are fixed, disabling the failed test scripts

Null merge from mysql-5.1

Null merge from mysql-5.1

Null-Merge from mysql-5.5

               DEREFERENCING UT_DBG_NULL_PTR
The abort() call is standard C but InnoDB only uses it in GCC
environments.  UT_DBG_USE_ABORT is not defined the code crashed
by dereferencing a null pointer instead of calling abort().
Other code throughout MySQL including ndb, sql, mysys and other
places call abort() directly.

This bug also affects innodb.innodb_bug14147491.test which fails
randomly on windows because of this issue. 

Approved by marko in http://rb.no.oracle.com/rb/r/1936/

Currently MySQL MSI installer on Windows installs MySQL in 
"per user" mode. It means that if a Windows machine has 
multiple users, they each can install MySQL independently. 
However the default path of MySQL is "C:\Program Files (x86)\MySQL\"
and when two users install MySQL on same machine, the installation
by second user just overwrites the MySQL files. This default shared 
location leads to the issue where if the second user uninstalls MySQL,
the installation files are removed for the first user as well.

In this fix, we are now making the default installation "per machine".
It means that when MySQL is installed with defaults options, all
users can see the shortcuts for MySQL in start menu(since installations 
is for all users). Also when any user relaunches the installer, it will 
consider that action uninstallation rather than installation for that user.

There are command line options in installer that can be used to undo the
"per machine" installation but will not consider that scenario.MySQL 
is a server product and it does not make a lot of sense to install it
differently for each user.

PROBLEM:
When large number of connections are continuously made
with wait_timeout of 600 seconds for  some hours, some
connections remain after wait_timeout expired and also
new connections get struck under the configuration and
the scenario reported in bug#16196591.
FIX:
The cause of this bug is the issue identified  and fixed in
the BUG#16088658 in 5.6.Also LOCK_thread_count contention 
issue fixed in BUG#15921866 in 5.6 need to be in 5.5 as 
well. Since the issue is not reproducible, it has been
verified at customer configuration the issue could not
be reproduced after a 48-hour test with a non-debug build               
which includes the above two fixes backported.

I/O IS ASYNC

rb://1934
approved by: Mikael Ronstrom (over email)
    
When submitting AIO read request don't signal that the thread is
about to wait on DISKIO

Analysis:
--------

As part of the fix for Bug#11757464, the 'out of memory' error
condition was not pushed to the diagnostic area as it requires
memory allocation. However in cases of SIGNAL/RESIGNAL 'out of
memory' error, the server may not be out of memory. Hence it
would be good to report the error in such cases.

Fix:
---

Push only non fatal 'out of memory' errors to the diagnostic area.
Since SIGNAL/RESIGNAL of 'out of memory' error may not be fatal,
the error is reported.

Manual up-merge from 5.1 to 5.5.