1. 01 Mar, 2016 1 commit
    • Arun Kuruvila's avatar
      Bug#21920657: SSL-CA FAILS SILENTLY IF THE PATH CANNOT BE · c7e68606
      Arun Kuruvila authored
                    FOUND
      
      Description:- Failure during the validation of CA
      certificate path which is provided as an option for 'ssl-ca'
      returns two different errors for YaSSL and OPENSSL.
      
      Analysis:- 'ssl-ca', option used for specifying the ssl ca
      certificate path. Failing to validate this certificate with
      OPENSSL returns an error, "ERROR 2026 (HY000): SSL
      connection error: SSL_CTX_set_default_verify_paths failed".
      While YASSL returns "ERROR 2026 (HY000): SSL connection
      error: ASN: bad other signature confirmation". Error
      returned by the OPENSSL is correct since
      "SSL_CTX_load_verify_locations()" returns 0 (in case of
      OPENSSL) for the failure and sets error as
      "SSL_INITERR_BAD_PATHS". In case of YASSL,
      "SSL_CTX_load_verify_locations()" returns an error number
      which is less than or equal to 0 in case of error. Error
      numbers for YASSL is mentioned in the file,
      'extra/yassl/include/openssl/ssl.h'(line no : 292). Also
      'ssl-ca' does not accept tilde home directory path
      substitution.
      
      Fix:- The condition which checks for the error in the
      "SSL_CTX_load_verify_locations()" is changed in order to
      accommodate YASSL as well. A logic is written in
      "mysql_ssl_set()" in order accept the tilde home directory
      path substitution for all ssl options.
      c7e68606
  2. 29 Feb, 2016 1 commit
  3. 26 Feb, 2016 2 commits
    • Yashwant Sahu's avatar
    • Venkatesh Duggirala's avatar
      BUG#20574550 MAIN.MERGE TEST CASE FAILS IF BINLOG_FORMAT=ROW · 29cc2c28
      Venkatesh Duggirala authored
      The main.merge test case was failing when tested using row based
      binlog format.
      
      While analyzing the issue it was found the following issues:
      
      a) The server is calling binlog related code even when a statement will
         not be binlogged;
      b) The child table list was not present into table structure by the time
         to generate the create table statement;
      c) The tables in the child table list will not be opened yet when
         generating table create info using row based replication;
      d) CREATE TABLE LIKE TEMP_TABLE does not preserve original table storage
         engine when using row based replication;
      
      This patch addressed all above issues.
      
      @ sql/sql_class.h
      
      Added a function to determine if the binary log is disabled to
        the current session. This is related with issue (a) above.
      
      @ sql/sql_table.cc
      
      Added code to skip binary logging related code if the statement
        will not be binlogged. This is related with issue (a) above.
      
      Added code to add the children to the query list of the table that
        will have its CREATE TABLE generated. This is related with issue (b)
        above.
      
      Added code to force the storage engine to be generated into the
        CREATE TABLE. This is related with issue (d) above.
      
      @ storage/myisammrg/ha_myisammrg.cc
      
      Added a test to skip a table getting info about a child table if the
        child table is not opened. This is related to issue (c) above.
      29cc2c28
  4. 23 Feb, 2016 3 commits
  5. 19 Feb, 2016 1 commit
  6. 11 Feb, 2016 1 commit
    • Nisha Gopalakrishnan's avatar
      BUG#22037930: INSERT IGNORE FAILS TO IGNORE FOREIGN KEY · d9c541cb
      Nisha Gopalakrishnan authored
                    CONSTRAINT.
      
      Analysis
      =======
      
      INSERT and UPDATE operations using the IGNORE keyword which
      causes FOREIGN KEY constraint violations reports an error
      despite using the IGNORE keyword.
      
      Foreign key violation errors were not ignored and reported
      as errors instead of warnings even when IGNORE was set.
      
      Fix
      ===
      Added code to ignore the foreign key violation errors and
      report them as warnings when the IGNORE keyword is used.
      d9c541cb
  7. 08 Feb, 2016 1 commit
    • Jon Olav Hauglid's avatar
      Bug#22680706: 5.5 DOES NOT BUILD WITH GCC5 · 1fb6d4e6
      Jon Olav Hauglid authored
      Fix the following two build warnings so that 5.5 can be compiled
      with GCC5.
      
      storage/innobase/dict/dict0crea.c:1143:21: error: logical not is only applied
      to the left hand side of comparison [-Werror=logical-not-parentheses]
         ut_a(!node->index == (err != DB_SUCCESS));
                           ^
      storage/innobase/log/log0recv.c:1770:20: error: logical not is only applied
      to the left hand side of comparison [-Werror=logical-not-parentheses]
        ut_ad(!allow_ibuf == mutex_own(&log_sys->mutex));
                          ^
      1fb6d4e6
  8. 05 Feb, 2016 1 commit
  9. 29 Jan, 2016 1 commit
    • Sreeharsha Ramanavarapu's avatar
      Bug #18823979: PS: UCS2 + CASE WHEN THEN ELSE CRASH IN · 718c7879
      Sreeharsha Ramanavarapu authored
                     ITEM_PARAM::SAFE_CHARSET_CONVERTER
      
      ISSUE:
      ------
      Charset conversion on a null parameter is not handled
      correctly.
      
      SOLUTION:
      ---------
      Item_param's charset converter does not handle the case
      where it might have to deal with a null value. This is
      fine for other charset converters since the value is not
      supplied to them at runtime.
      
      The fix is to check if the parameter is now set to null and
      return an Item_null object. Also, there is no need to
      initialize Item_param's cnvitem in the constructor to a
      string. This can be done in
      ITEM_PARAM::SAFE_CHARSET_CONVERTER itself.
      
      Members of Item_param, cnvbuf and cnvstr, have been removed
      and cnvitem has been made a local variable in
      ITEM_PARAM::SAFE_CHARSET_CONVERTER.
      718c7879
  10. 28 Jan, 2016 1 commit
    • Ajo Robert's avatar
      Bug #16912362 LOAD DATA INFILE CLAIMS TO BE HOLDING · 01d41f68
      Ajo Robert authored
      'SYSTEM LOCK' IN PROCESSLIST
      
      Analysis
      =========
      Show processlist shows 'System Lock' in 'State' field while
      LOAD DATA INFILE is running.
      
      thd->proc_info update is missing in LOAD DATA INFILE path.
      Thus any request will get last unpdated status from lock_table()
      during open_table().
      
      Fix:
      =======
      Update state information from LOAD DATA INFILE path.
      01d41f68
  11. 27 Jan, 2016 2 commits
  12. 26 Jan, 2016 1 commit
    • Jon Olav Hauglid's avatar
      Bug#21770366 backport bug#21657078 to 5.5 and 5.6 · a204ce5b
      Jon Olav Hauglid authored
      Post-push fix: The problem was that condition variable
      timeouts could in some cases (slow machines and/or short
      timeouts) be infinite.
      
      When the number of milliseconds to wait is computed, the
      end time is computed before the now() time. This can result
      in the now() time being later than the end time, leading to
      negative timeout. Which after conversion to unsigned becomes
      ~infinite.
      
      This patch fixes the problem by explicitly checking if we
      get negative timeout and then using 0 if this is the case.
      a204ce5b
  13. 22 Jan, 2016 1 commit
  14. 20 Jan, 2016 1 commit
  15. 17 Jan, 2016 1 commit
    • Knut Anders Hatlen's avatar
      Bug#21682356: STOP INJECTING DATA ITEMS IN AN ERROR MESSAGE · 95825fa2
      Knut Anders Hatlen authored
                    GENERATED BY THE EXP() FUNCTION
      
      When generating the error message for numeric overflow, pass a flag to
      Item::print() that prevents it from expanding constant expressions and
      parameters to the values they evaluate to.
      
      For consistency, also pass the flag to Item::print() when
      Item_func_spatial_collection::fix_length_and_dec() generates an error
      message. It doesn't make any difference at the moment, since constant
      expressions haven't been evaluated yet when this function is called.
      95825fa2
  16. 15 Jan, 2016 1 commit
    • Shaohua Wang's avatar
      BUG#22530768 Innodb freeze running REPLACE statements · 93a6142d
      Shaohua Wang authored
      we can see from the hang stacktrace, srv_monitor_thread is blocked
      when getting log_sys::mutex, so that sync_arr_wake_threads_if_sema_free
      cannot get a change to break the mutex deadlock.
      
      The fix is simply removing any mutex wait in srv_monitor_thread.
      
      Patch is reviewed by Sunny over IM.
      93a6142d
  17. 12 Jan, 2016 1 commit
    • Shaohua Wang's avatar
      BUG#22530768 Innodb freeze running REPLACE statements · 79032a7a
      Shaohua Wang authored
      we can see from the hang stacktrace, srv_monitor_thread is blocked
      when getting log_sys::mutex, so that sync_arr_wake_threads_if_sema_free
      cannot get a change to break the mutex deadlock.
      
      The fix is simply removing any mutex wait in srv_monitor_thread.
      
      Patch is reviewed by Sunny over IM.
      79032a7a
  18. 11 Jan, 2016 5 commits
  19. 08 Jan, 2016 1 commit
    • Sreeharsha Ramanavarapu's avatar
      Bug #22232332: SAVING TEXT FIELD TO TEXT VARIABLE IN A · 863f7ceb
      Sreeharsha Ramanavarapu authored
                     PROCEDURE RESULTS IN GARBAGE BYTES
      
      Issue:
      -----
      This problem occurs under the following conditions:
      
      a) Stored procedure has a variable is declared as TEXT/BLOB.
      b) Data is copied into the the variable using the
         SELECT...INTO syntax from a TEXT/BLOB column.
      
      Data corruption can occur in such cases.
      
      SOLUTION:
      ---------
      The blob type does not allocate space for the string to be
      stored. Instead it contains a pointer to the source string.
      Since the source is deallocated immediately after the
      select statement, this can cause data corruption.
      
      As part of the fix for Bug #21143080, when the source was
      part of the table's write-set, blob would allocate the
      neccessary space. But this fix missed the possibility that,
      as in the above case, the target might be a variable.
      
      The fix will add the copy_blobs check that was removed by
      the earlier fix.
      863f7ceb
  20. 07 Jan, 2016 1 commit
    • Ajo Robert's avatar
      Bug#21770366 backport bug#21657078 to 5.5 and 5.6 · 3d1306f7
      Ajo Robert authored
      Problem Statement
      =========
      Fix various issues when building MySQL with Visual Studio 2015.
      
      Fix:
      =======
      - Visual Studio 2015 adds support for timespec. Add check and
        related code to use this and only use our replacement if
        timespec is not defined.
      - Rename lfind/lsearch to my* to avoid redefinition problems.
      - Set default value for TMPDIR to "" on Windows as P_tmpdir
        no longer exists.
      - using VS definition of snprintf if available
      - tzname are now renamed to _tzname.
      3d1306f7
  21. 04 Jan, 2016 1 commit
    • V S Murthy Sidagam's avatar
      Description: yaSSL was only handling the cases of zero or · 8c65e082
      V S Murthy Sidagam authored
      one leading zeros for the key agreement instead of
      potentially any number.
      There is about 1 in 50,000 connections to fail
      when using DHE cipher suites.  The second problem was the
      case where a server would send a public value shorter than
      the prime value, causing about 1 in 128 client connections
      to fail, and also caused the yaSSL client to read off the
      end of memory.
      All client side DHE cipher suite users should update.
      Note: The patch is received from YaSSL people
      8c65e082
  22. 31 Dec, 2015 1 commit
    • Sreeharsha Ramanavarapu's avatar
      Bug #21564557: INCONSISTENT OUTPUT FROM 5.5 AND 5.6 · cb15cce7
      Sreeharsha Ramanavarapu authored
                     UNIX_TIMESTAMP(STR_TO_DATE('201506', "%Y%M"
      
      Issue:
      -----
      When an invalid date is supplied to the UNIX_TIMESTAMP
      function from STR_TO_DATE, no check is performed before
      converting it to a timestamp value.
      
      SOLUTION:
      ---------
      Add the check_date function and only if it succeeds,
      proceed to the timestamp conversion.
      
      No warning will be returned for dates having zero in
      month/date, since partial dates are allowed. UNIX_TIMESTAMP
      will return only a zero for such values.
      
      The problem has been handled in 5.6+ with WL#946.
      cb15cce7
  23. 29 Dec, 2015 1 commit
    • Karthik Kamath's avatar
      BUG#21902059: "CREATE TEMPORARY TABLE SELECT ..." AND BIT(1) · 1ec594dd
      Karthik Kamath authored
                     COLUMNS
      
      ANALYSIS:
      =========
      A valgrind error is reported when CREATE TABLE .. SELECT
      involving BIT columns triggers a column type redefinition.
      
      In general the pack_flag is set for BIT columns in
      'mysql_prepare_create_table()'. However, during the above
      operation, redefined column types was handled after the
      special handling for BIT columns and thus pack_flag ended
      up not being set correctly triggering the valgrind error.
      
      FIX:
      ====
      The patch fixes this problem by setting pack_flag correctly
      for BIT columns in the case of column type redefinition.
      1ec594dd
  24. 16 Dec, 2015 2 commits
    • Balasubramanian Kandasamy's avatar
      Bug#22361702 - /USR/BIN/MYSQL-SYSTEMD-START DOES NOT RETURN CONTROL TO COMMAND LINE · 3c9ba967
      Balasubramanian Kandasamy authored
      If the configuration files contains multiple datadir lines, use the last datadir
      entry in the RPM installation scripts
      3c9ba967
    • Sujatha Sivakumar's avatar
      Bug#22278455: MYSQL 5.5:RPL_BINLOG_INDEX FAILS IN VALGRIND. · c5ba7067
      Sujatha Sivakumar authored
      Problem:
      =======
      rpl_binlog_index.test fails with following valgrind error.
      
      line
      Conditional jump or move depends on uninitialised value(s)
      at 0x4C2F842: __memcmp_sse4_1 (in /usr/lib64/valgrind/
      vgpreload_memcheck-amd64-linux.so)
      0x739E39: find_uniq_filename(char*) (log.cc:2212)
      0x73A11B: MYSQL_LOG::generate_new_name(char*, char const*)
      (log.cc:2492)
      0x73A1ED: MYSQL_LOG::init_and_set_log_file_name(char const*,
      char const*, enum_log_type, cache_type) (log.cc:2289)
      0x73B6F5: MYSQL_BIN_LOG::open(char const*, enum_log_type,
      
      
      Analysis and fix:
      =================
      This issue was fixed as part of Bug#20459363 fix in 5.6 and
      above. Hence backporting the fix to MySQL-5.5.
      c5ba7067
  25. 01 Dec, 2015 1 commit
    • Venkatesh Duggirala's avatar
      Bug#21205695 DROP TABLE MAY CAUSE SLAVES TO BREAK · 2735f0b9
      Venkatesh Duggirala authored
          Problem:
          ========
          1) Drop table queries are re-generated by server
          before writing the events(queries) into binlog
          for various reasons. If table name/db name contains
          a non regular characters (like latin characters),
          the generated query is wrong. Hence it breaks the
          replication.
          2) In the edge case, when table name/db name contains
          64 characters, server is throwing an assert
          assert(M_TBLLEN < 128)
          3) In the edge case, when db name contains 64 latin
          characters, binlog content is interpreted badly
          which is leading replication failure.
      
          Analysis & Fix :
          ================
          1) Parser reads the table name from the query and converts
          it to standard charset(utf8) and stores it in table_name variable.
          When drop table query is regenerated with the same table_name
          variable, it should be converted back to the original charset
          from standard charset(utf8).
      
          2) Latin character takes two bytes for each character. Limit
          of the identifier is 64. SYSTEM_CHARSET_MBMAXLEN is set to '3'.
          So there is a possiblity that tablename/dbname contains 3 * 64.
          Hence assert is changed to
          (M_TBLLEN <= NAME_CHAR_LEN*SYSTEM_CHARSET_MBMAXLEN)
      
          3) db_len in the binlog event header is taking 1 byte.
             db_len is ranged from 0 to 192 bytes (3 * 64).
             While reading the db_len from the event, server
             is casting to uint instead of uchar which is leading
             to bad db_len. This problem is fixed by changing the
             cast type to uchar.
      2735f0b9
  26. 21 Nov, 2015 1 commit
  27. 20 Nov, 2015 2 commits
    • Chaithra Gopalareddy's avatar
      Bug#19941403: FATAL_SIGNAL(SIG 6) IN BUILD_EQUAL_ITEMS_FOR_COND | IN SQL/SQL_OPTIMIZER.CC:1657 · a7fb5aec
      Chaithra Gopalareddy authored
      Problem:
      At the end of first execution select_lex->prep_where is pointing to
      a runtime created object (temporary table field). As a result
      server exits trying to access a invalid pointer during second
      execution.
      
      Analysis:
      While optimizing the join conditions for the query, after the
      permanent transformation, optimizer makes a copy of the new
      where conditions in select_lex->prep_where. "prep_where" is what
      is used as the "where condition" for the query at the start of execution.
      W.r.t the query in question, "where" condition is actually pointing
      to a field in the temporary table. As a result, for the  second
      execution the pointer is no more valid resulting in server exit.
      
      Fix:
      At the end of the first execution, select_lex->where will have the
      original item of the where condition.
      Make prep_where the new place where the original item of select->where
      has to be rolled back.
      Fixed in 5.7 with the wl#7082 - Move permanent transformations from
      JOIN::optimize to JOIN::prepare
      
      Patch for 5.5 includes the following backports from 5.6:
      
      Bugfix for Bug12603141 - This makes the first execute statement in the testcase
      pass in 5.5
      
      However it was noted later in in Bug16163596 that the above bugfix needed to
      be modified. Although Bug16163596 is reproducible only with changes done for
      Bug12582849, we have decided include the fix.
      
      Considering that Bug12582849 is related to Bug12603141, the fix is
      also included here. However this results in Bug16317817, Bug16317685,
      Bug16739050. So fix for the above three bugs is also part of this patch.
      a7fb5aec
    • Sreeharsha Ramanavarapu's avatar
      Bug #22214867: MYSQL 5.5: MAIN.SUBSELECT AND OTHERS FAIL · f3554bf1
      Sreeharsha Ramanavarapu authored
                     WITH NEW VALGRIND
      
      Issue:
      ------
      Function signature in valgrind.supp requires a change with
      valgrind 3.11. Static function is replaced with wild card.
      f3554bf1
  28. 19 Nov, 2015 1 commit
    • Venkatesh Duggirala's avatar
      Bug#17047208 REPLICATION DIFFERENCE FOR MULTIPLE TRIGGERS · bb56c30a
      Venkatesh Duggirala authored
          Problem & Analysis: If DML invokes a trigger or a
          stored function that inserts into an AUTO_INCREMENT column,
          that DML has to be marked as 'unsafe' statement. If the
          tables are locked in the transaction prior to DML statement
          (using LOCK TABLES), then the same statement is not marked as
          'unsafe' statement. The logic of checking whether unsafeness
          is protected with if (!thd->locked_tables_mode). Hence if
          we lock the tables prior to DML statement, it is *not* entering
          into this if condition. Hence the statement is not marked
          as unsafe statement.
      
          Fix: Irrespective of locked_tables_mode value, the unsafeness
          check should be done. Now with this patch, the code is moved
          out to 'decide_logging_format()' function where all these checks
          are happening and also with out 'if(!thd->locked_tables_mode)'.
          Along with the specified test case in the bug scenario
          (BINLOG_STMT_UNSAFE_AUTOINC_COLUMNS), we also identified that
          other cases BINLOG_STMT_UNSAFE_AUTOINC_NOT_FIRST,
          BINLOG_STMT_UNSAFE_WRITE_AUTOINC_SELECT, BINLOG_STMT_UNSAFE_INSERT_TWO_KEYS
          are also protected with thd->locked_tables_mode which is not right. All
          of those checks also moved to 'decide_logging_format()' function.
      bb56c30a
  29. 18 Nov, 2015 1 commit
  30. 13 Nov, 2015 1 commit
    • Ajo Robert's avatar
      Bug#20691429 ASSERTION `CHILD_L' FAILED IN STORAGE/MYISAMMRG/ · 6d1e2fbc
      Ajo Robert authored
      HA_MYISAMMRG.CC:631
      
      Analysis
      ========
      Any attempt to open a temporary MyISAM merge table consisting
      of a view in its list of tables (not the last table in the list)
      under LOCK TABLES causes the server to exit.
      
      Current implementation doesn't perform sanity checks during
      merge table creation. This allows merge table to be created
      with incompatible tables (table with non-myisam engine),
      views or even with table doesn't exist in the system.
      
      During view open, check to verify whether requested view
      is part of a merge table is missing under LOCK TABLES path
      in open_table(). This leads to opening of underlying table
      with parent_l having NULL value. Later when attaching child
      tables to parent, this hits an ASSERT as all child tables
      should have parent_l pointing to merge parent. If the operation
      does not happen under LOCK TABLES mode, open_table() checks
      for view's parent_l and returns error.
      
      Fix:
      ======
      Check added before opening view Under LOCK TABLES in open_table()
      to verify whether it is part of merge table. Error is returned
      if the view is part of a merge table.
      6d1e2fbc