Problem: A corrupted header length in FORMAT_DESCRIPTION_LOG_EVENT
      can cause server to crash.
      Analysis: FORMAT_DESCRIPTION_EVENT will be considered invalid if
      header len is too small (i.e. below OLD_HEADER_LEN).
      
      Format_description_log_event:: Format_description_log_event(...)
      {
        ...
        if ((common_header_len=buf[ST_COMMON_HEADER_LEN_OFFSET]) < OLD_HEADER_LEN)
          DBUG_VOID_RETURN; /* sanity check */
        ...
        post_header_len= my_memdup(...)
      }
      
      In that case Format_description_log_event constructor will return early,
      without allocating any memory for post_header_len. Thence this variable is
      left uninitialized and making server to crash when server is trying
      to free the uninitialized value.
      
      Fix: When Format_description_log_event constructor returns early, assign
      NULL to post_header_len.

No commit message

Problem:

We maintain two rb trees in each dict_table_t.  The foreign_rbt must be in
sync with foreign_list.  The referenced_rbt must be in sync with
referenced_list. There is one function which checks this consistency and it
failed, resulting in an assert failure.

The root cause of the problem was identified that the search order was 
lost in the referenced_rbt.  This is because while renaming the table,
we didn't not refresh this referenced_rbt.

Solution:

When a foreign key is renamed, we must delete and re-insert into both
foreign_rbt and referenced_rbt.  

rb#6412 approved by Jimmy.

               LIES ABOUT SUITE_LEN_
               and
Bug#19355577 : YASSL PRE-AUTH BUFFER OVERFLOW WHEN CLIENT
               LIES ABOUT COMP_LEN_

Description : Updating yaSSL to version 2.3.4.

Several string functions have optimizations for constant
sub-expressions which lead to setting max_length == 0.

For subqueries, where we need a temporary table to holde the result,
we need to ensure that we use a VARCHAR(0) column rather than a
CHAR(0) column when such expressions take part in grouping.
With CHAR(0) end_update() may write garbage into the next field.

                COLLATIONS ARE USED.

ISSUE :
-------
Code points of HALF WIDTH KATAKANA in SJIS/CP932 range from
A1 to DF. In function my_wildcmp_mb_bin_impl while comparing
such single byte code points, there is a code which compares
signed character with unsigned character. Because of this,
comparisons of two same code points representing a HALF
WIDTH KATAKANA character always fails.

Solution:
---------
A code point of HALF WIDTH KATAKANA at-least need 8 bits.
Promoting the variable from uchar to int will fix the issue.

- Reverted version variable 

Follow-up patch. Removed unwanted code.

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