Description: Backporting BUG#16513435 to 5.5 and 5.6
This is a fix for REMOTE PREAUTH USER ENUMERATION FLAW bug

Reverted change due to mtr test failure.

No commit message

Post-push patch. Changing file permission of "scripts/mysqlaccess.conf".

Backporting patch committed for bug 18008907 to 5.5
and 5.6.

Post push fix: add execute bit on perl script.

Mysqldump overflows stack buffer when copying table name from commandline arguments resulting in stack corruption and ability to execute arbitrary code.

Fix: Check length of all positional arguments passed to mysqldump is smaller than NAME_LEN.
Note: Mysqldump heavily depends on that database objects (databases, tablespaces, tables, etc) are limited to small size (now it is 64).

The test case makes use of the fine DEBUG_SYNC facility. Furthermore,
since it needs synchronization on internal threads (dump and SQL
threads) the server code has DEBUG_SYNC commands internally deployed
and activated through the DBUG_EXECUTE_IF macro. The internal
DBUG_SYNC commands are then controlled from the test case through the
DEBUG variable.

There were three problems around the DEBUG + DEBUG_SYNC facility
usage:

1. When signaling the SQL thread to continue, the test would reset
   immediately the DEBUG_SYNC variable. This could mean that the SQL
   thread might loose the signal and continue to wait forever;

2. A similar scenario was happening with the dump thread on the
   master. This thread was instructed to wait, and later it would be
   signaled to continue, but immediately after the DEBUG_SYNC would be
   reset. This could lead to the dump thread missing the signal and
   wait forever;

3. The test was not cleaning itself up with respect to the
   instrumentation of the dump thread. This would leave the
   conditional execution of an internal DEBUG_SYNC command active
   (through the usage of DBUG_EXECUTE_IF). 

We fix #1 and #2 by waiting for the threads to receive the signal and
only then issue the reset. We fix #3 by reseting the DEBUG variable,
thus deactivating the dump thread internal DEBUG_SYNC command.

               CERTAIN MAX_HEAP_TABLE_SIZE VALUES

Followup patch to fix failure on Window machine.

BACKGROUND:
This bug is a followup on Bug#16368875.
The assertion failure happens because in SQL layer the key
does not get promoted to PRIMARY KEY but InnoDB takes it
as PRIMARY KEY.

ANALYSIS:
Here we are trying to create an index on POINT (GEOMETRY)
data type which is a type of BLOB (since GEOMETRY is a
subclass of BLOB).
In general, we can't create an index over GEOMETRY family
type field unless we specify the length of the
keypart (similar to BLOB fields).
Only exception is the POINT field type. The POINT column
max size is 25. The problem is that the field is not treated
as PRIMARY KEY when we create a index on POINT column using
its max column size as key part prefix. The fix would allow
index on POINT column to be treated as PRIMARY KEY.

FIX:
Patch for Bug#16368875 is extended to take into account
GEOMETRY datatype, POINT in particular to consider it
as PRIMARY KEY in SQL layer.

Fix:
---
The issue reported is same as the BUG#14117018.
Hence backporting the patch from mysql-trunk
to mysql-5.5 and mysql-5.6

Bug#16415173 CRLF INSTEAD OF LF IN SQL-BENCH SCRIPTS
      
Correct perms and converts from Windows style to UNIX style line endings on some files.
Fix perms on installed ini files.

(MySQL 5.5 version)

                WITH CERTAIN MAX_HEAP_TABLE_SIZE VALUES

Description:
When the  system variable 'max_heap_table_size'
is set to 20GB, the server crashes on creation of a
temporary tables or tables using MEMORY storage engine.

Analysis:
The variable 'max_record' determines the amount heap
allocated for the records of the table. This value
is determined using the 'max_heap_table_size' variable.
'records_in_block' in turn uses the max_records to
determine the number of records per block.

When the 'max_heap_table_size' is set to 20GB, then
the 'records_in_block' is calculated to a value of
2^28.

The size of the block determined by multiplying the
'records_in_block' and 'recbuffer' results in overflow
and hence the value becomes zero. As a result, zero bytes
of the heap is allocated for the table. This will
result in a server crash when the table is accessed.

Fix:
The variables 'records_in_block' and 'recbuffer' are
typecasted to 'unsigned long' while calculating the
size of the block.

                                        PRIMARY_KEY_NO == 0 

This bug is a backport of the following revision of 5.6 source tree:
# committer: Gopal Shankar <gopal.shankar@oracle.com>
# branch nick: priKey56
# timestamp: Wed 2013-05-29 11:11:46 +0530
# message:
#   Bug#16368875 INNODB: FAILING ASSERTION:

Set CMP0026 and CMP0045 policies when using CMake 
version 3 or higher to restore old CMake behavior.

              CORRUPTS FRM

Analysis:
---------
ALTER TABLE on a partitioned table resulted in the wrong
engine being written into the table's FRM file and displayed
in SHOW CREATE TABLE.

The prep_alter_part_table() modifies the partition_info object
for TABLE instance representing the old version of table.
If the ALTER TABLE ENGINE statement fails, the partition_info
object for the TABLE contains the altered storage engine name.
The SHOW CREATE TABLE uses the TABLE object to display the table
information, hence displays incorrect storage engine for the table.
Also a subsequent successful ALTER TABLE operation will write the
incorrect engine information into the FRM file.

Fix:
---
A copy of the partition_info object is created before modification so
that any changes would not cause the the original partition_info object
to be modified if the ALTER TABLE fails.(Backported part of the code
provided as fix for bug#14156617 in mysql-5.6.6).

Backport of the fix:

: Bug 18017820: BISON 3 BREAKS MYSQL BUILD
: ========================================    
: 
: The source of the reported problem is a removal of a few deprecated
: things from Bison 3.x: 
: * YYPARSE_PARAM macro (use the %parse-param bison directive instead),
: * YYLEX_PARAM macro (use %lex-param instead),
: 
: The fix removes obsolete macro calls and introduces use of
: %parse-param and %lex-param directives.

This is the 5.5/5.6 version of the patch.

Add deprecation warning for timed_mutexes.

             DISCONNECT CON1 AND CON2
  
Problem:
The test suite/binlog/t/binlog_killed.test makes the connections
con1 and con2 but forgets to disconnect them + wait till that
operation is finished at test end.
This mistake has the potential to harm subsequent tests in
case these tests depend on the content of the processlist.
 
Solution:
Added disconnect + wait_until_disconnected.inc 
within the test cleanup.

No commit message

NON-EXISTS RECORDS

Problem:
========
In RBR replication, master deletes a record but the record
don't exist on slave. when slave tries to apply the
Delete_row_log_event from master, it will result in an
assert on slave.

Analysis:
========
This problem exists not only with Delete_rows event but also
with Update_rows event as well. Trying to update a non
existing row on the slave from the master will cause the
same assert.  This assert occurs only for the tables that
doesn't have primary keys and which basically require
sequential scan to be done to locate a record. This bug
occurs only with innodb engine not with myisam.

When update or delete rows is executed on a slave on a table
which doesn't have primary key the updated record is stored
in a buffer named table->record[0] and the same is copied to
table->record[1] so that during sequential scan
table->record[0] can reloaded with fetched data from the
table and compared against table->record[1].  In a special
case where there is no record on the slave side scan will
result in EOF in that case we reinit the scan and we try to
compare record[0]  with record[1] which are basically the
same. This comparison is incorrect. Since they both are the
same record_compare() will report that record is found and
we try to go ahead and try to update/delete non existing
row. Ideally if the scan results in EOF means no data found
hence no need to do a record_compare() at all.

Fix:
===
Avoid comparision of records on EOF.

SLOW/CRASHES SEMAPHORE

Problem:

There are 2 lakh tables - fk_000001, fk_000002 ... fk_200000.  All of them
are related to the same parent_table through a foreign key constraint.
When the parent_table is loaded into the dictionary cache, all the child table
will also be loaded.  This is taking lot of time.  Since this operation happens
when the dictionary latch is taken, the scenario leads to "long semaphore wait"
situation and the server gets killed.

Analysis:

A simple performance analysis showed that the slowness is because of the
dict_foreign_find() function.  It does a linear search on two linked list
table->foreign_list and table->referenced_list, looking for a particular
foreign key object based on foreign->id as the key.  This is called two
times for each foreign key object.

Solution:

Introduce a rb tree in table->foreign_rbt and table->referenced_rbt, which
are some sort of index on table->foreign_list and table->referenced_list
respectively, using foreign->id as the key.  These rbt structures will be
solely used by dict_foreign_find().  

rb#5599 approved by Vasil

For charsets with no binary collation: use my_charset_bin.

                                IN
                                SSL_CTX_LOAD_VERIFY_
                                LOCATIONS()
                                and
                                OFF-BY-ONE PROBLEM IN
                                VOID CERTDECODER::
                                GETDATE(DATETYPE DT)
                                IN ASN.CPP

Description : Fixes corner cases in yassl code.
              Refer to bug page for details.

Item_func_ltrim::val_str did not handle multibyte charsets.
Fix: factor out common code for Item_func_trim and Item_func_ltrim.

              MYSQLADMIN IN PROCESSES LIST

Description: Checking the process status (with ps -ef)  
while executing "mysqladmin" with old password and new 
password via command-line will show the new password in the
process list sporadically.

Analysis: The old password is being masked by "mysqladmin".
So masking the new password in the similar manner would 
reduce hitting the bug. But this would not completely fix
the bug, because if "ps -ef " command hits the mysqladmin
before it masks the passwords it will show both the old and
new passwords in the process list. But the chances of
hitting this is very less.

Fix: The new password also masked in the similar manner
that of the --password argument.