Description: mysql_upgrade fails with below error, 
when there are duplicate entries(like 'root'@'LOCALHOST'
and 'root'@'localhost') in mysql.user table.
ERROR 1062 (23000) at line 1140: Duplicate entry 'localhost-root' for key 'PRIMARY'
FATAL ERROR: Upgrade failed

Analysis: As part of the bug 12917151 fix we are 
making all the hostnames as lower case hostnames.
So, this has been done by mysql_upgrade.
In case of above mentioned duplicate entries 
mysql_upgrade tries to change hostname to lowercase.
Since there is already 'root'@'localhost' exists.
it is failing with "duplicate entry" error.

Fix: Since its a valid error failure. We are 
making the error more verbose. So, that user will
delete the duplicate errors manually.
Along with existing error we are printing below
error as well.
ERROR 1644 (45000) at line 1153: Multiple accounts exist for @user_name, @host_name that differ only in Host lettercase; remove all except one of them

the 5.5 version of the fix.
Added a call to X509_verify_cert_error_string() into the client certificate
verification code.

No commit message

Description: Sometimes when killing the mysql command line client with
KILL -2(SIGINT), mysql client core dumps as a result of a double free or
corruption.

Analysis: When we run the mysql client in command line mode it will goes
to mysql_end() and frees many data structures. At the same time (i.e
after some data structures are freed), if we give "KILL -2" signal then
the signal will be handled with function handle_kill_signal() and as
part of it will again calls mysql_end() and goes with free() to the
already freed data structure for batch_readline_end() function, which
causes core dump.

Fix: Ignoring SIGQUIT and SIGINT signals when cleanup process starts.
This will help in resolving the double free issues, which occurs 
in case the signal handler function is started in between of the 
clean up function.
For 5.6 we need to ignore SIGHUP also.

No commit message

              GOES AWAY, MYSQL QUITS WORKING.

Analysis:
-----------------
Issue in this bug and in bug 11907705 is, the socket file or
fifo file is set for general log at command line while starting
the server. But currently, only regular file can be set for the 
general log. Instead of reporting any error, the provided files
are opened for writing and continued. Because of this issues
mentioned in the bug reports are seen.

As mentioned, only when any non-regular file is set for general
log at command line while starting the server, these issues are
seen. If general log file is set to non-regular file from CLI
using system variable general_log_file then error is reported.

These issues can also be faced with slow query log file, if it is
set to non-regular file.

Fix:
-----------------
Currently while starting the server if we fail to open log file
then we report an error, disable logging to file and continue.
To fix issue reported code is modified to check whether file
is regular file or not before opening it. If file is not a 
regular file then error is logged to error log and logging to 
file is disabled.

  Add some code adapted from 5.6 to check for "real" DTrace. If found,
  and system is Linux, we simply set DTRACE to OFF. Otherwise no change.

  Build will still break if one tries to manually set DTRACE to ON.

No commit message

IN RECOVERY

During redo log processing, the data dictionary is not available. We should
check it in dict_find_table_by_space() to prevent SEGV error.

rb#5678, approved by Jimmy.

For rpad() and lpad(): verify that the padding string is well-formed.

      
Problem:
If leading zeroes of fractional part of a decimal
number exceeds 45, mod operation on the same fails.
      
Analysis:
Currently there is a miscalcultion of fractional
part for very small decimals in do_div_mod.
      
For ex:
For 0.000(45 times).....3
length of the integer part becomes -5 (for a length of one,
buffer can hold 9 digits. Since number of zeroes are 45, integer
part becomes 5) and it is negative because of the leading
zeroes present in the fractional part.
Fractional part is the number of digits present after the
point which is 46 and therefore rounded off to the nearest 9
multiple which is 54. So the length of the resulting fractional
part becomes 6.
      
Because of this, the combined length of integer part and fractional
part exceeds the max length allocated which is 9 and thereby failing.
      
Solution:
In case of negative integer value, it indicates there are
leading zeroes in fractional part. As a result stop1 pointer 
should be set not just based on frac0 but also intg0. This is
because the detination buffer will be filled with 0's for the length
of intg0.

Problem:

When a unique secondary index is scanned for duplicate checking, gap locks
were not taken if the transaction had isolation level <= READ COMMITTED. 
This change was done while fixing Bug #16133801 UNEXPLAINABLE INNODB UNIQUE
INDEX LOCKS ON DELETE + INSERT WITH SAME VALUES (rb#2035). Because of this
the duplicate check logic failed, and resulted in duplicate values in unique
secondary index.

Solution:

When a unique secondary index is scanned for duplicate checking, gap locks
must be taken irrespective of the transaction isolation level.  This is
achieved by reverting rb#2035.

rb#5910 approved by Jimmy

Description:
THREAD_CONCURRENCY is deprecated and there is no 
deprecation warning message while setting this variable
while starting the server.

Analysis:
This variable is specific to Solaris 8 and earlier systems
and is ignored on all other platforms. But since many 
customers, who uses other than Solaris, still has this 
variable in their configuration file, it is important to
have a deprecation warning.

Fix:
THREAD_CONCURRENCY deprecation warning message is added.

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).

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: