1. 09 Nov, 2015 1 commit
  2. 07 Nov, 2015 1 commit
  3. 06 Nov, 2015 1 commit
    • Harin Vadodaria's avatar
      Bug#21973610: BUFFER OVERFLOW ISSUES · 0dbd5a87
      Harin Vadodaria authored
      Description : Incorrect usage of sprintf/strcpy caused
                    possible buffer overflow issues at various
                    places.
      
      Solution : - Fixed mysql_plugin and mysqlshow
                 - Fixed regex library issues
      
      Reviewed-By : Georgi Kodinov <georgi.kodinov@oracle.com>
      Reviewed-By : Venkata S Murthy Sidagam <venkata.sidagam@oracle.com>
      0dbd5a87
  4. 05 Nov, 2015 1 commit
  5. 04 Nov, 2015 1 commit
  6. 03 Nov, 2015 2 commits
    • Sreeharsha Ramanavarapu's avatar
      Bug #22123583: MYSQL 5.5: MAIN.SP HAS VALGRIND ISSUES · 75bfdea4
      Sreeharsha Ramanavarapu authored
      Issue:
      -----
      When a varchar column is used to fill the record in an
      internal temporary table, the length of the string stored
      in the column is not taken into account. Instead the
      default length of packed data is used to copy with memmove.
      This will cause valgrind issues since some bytes are
      uninitialized.
      
      SOLUTION:
      ---------
      The solution is to take into account the length of the
      string stored in the column while filling the record.
      
      This fix is a backport of BUG#13389854.
      75bfdea4
    • Sreeharsha Ramanavarapu's avatar
      Bug #22023218: MYSQL 5.5: MAIN.FULLTEXT HAS VALGRIND ISSUES. · 5e9a50ef
      Sreeharsha Ramanavarapu authored
      
      Issue
      -----
      This problem occurs when varchar columns are used in a
      internal temporary table. The type of the field is set
      incorrectly to the generic FIELD_NORMAL type. This in turn
      results in an inaccurate calculation of the record length.
      Valgrind issues will occur since initialization has not
      happend for some bytes.
      
      Fix
      ----
      While creating the temporary table, the type of the field
      needs to be to set FIELD_VARCHAR. This will allow myisam
      to calculate the record length accurately.
      
      This fix is a backport of BUG#13350136.
      5e9a50ef
  7. 02 Nov, 2015 1 commit
    • Chaithra Gopalareddy's avatar
      Bug#20755389 SERVER CRASHES IN ITEM_FUNC_GROUP_CONCAT::FIX_FIELDS ON · 9b6ac734
      Chaithra Gopalareddy authored
                     2ND EXECUTION OF PS
      
      Description:
      ------------
      When MySQL calls 'EXECUTE stmt' firstly to deal with ORDER BY clause which is
      similar with 'ORDER BY 1,(t2a.f2+1)' in find_order_in_list(), it believes the
      first expression is a position, the function replaces the pointer of the first
      expression with Item_field object associated with a temporary table field,
      then releases it after the end of the execution, that behavior destroys the
      pointer of first expression.
      
      After that, when MySQL calls 'EXECUTE stmt' once more, the first expression
      points to an invalid pointer, so it crashed.
      
      Fix:
      ----
      If an item of ORDER clause is a location, reset 'args' with a original value.
      9b6ac734
  8. 29 Oct, 2015 1 commit
    • Shishir Jaiswal's avatar
      DESCRIPTION · 1942506b
      Shishir Jaiswal authored
      ===========
      When doing an upgrade, you execute mysql_upgrade. If
      mysql_upgrade fails to connect or it connects with a user
      without the proper privileges, it will return the error:
      
          FATAL ERROR: Upgrade failed
      
      which is not very informative.
      
      ANALYSIS
      ========
      
      In main() and check_version_match(), the condition for
      errors are clubbed together and throw the same error msg.
      The functions need to be splitted up and the corresponding
      error msgs have to be displayed.
      
      FIX
      ===
      Splitted the functions and added the specific error msg.
      1942506b
  9. 26 Oct, 2015 1 commit
  10. 22 Oct, 2015 1 commit
    • Mithun C Y's avatar
      Bug #20447262: REPEATED EXECUTION OF PREPARED STATEMENTS FAILS, IF DEFAULT DATABASE IS CHANGED. · dea23408
      Mithun C Y authored
      Issue:
      ======
      While re-preparing the statement in
      Prepared_statement::swap_prepared_statement for swapping
      the database of PS we only swapped the db string but not
      its length. This resulted in mismatch between the actual
      string and its length. In one particular case where db
      of PS was dropped, we have db as null pointer and length
      as non-zero. strdup which used above values resulted in
      invalid memory access.
      
      Solution:
      =========
      In Prepared_statement::swap_prepared_statement also swap
      db_length along with db variable. Also, remove
      DBUG_ASSERT(db_length == copy->db_length) as this have
      no meaning if they are 2 different entities.
      dea23408
  11. 16 Oct, 2015 1 commit
  12. 14 Oct, 2015 2 commits
    • Arun Kuruvila's avatar
      Bug #21235226 : THE --ENABLE-CLEARTEXT-PLUGIN IS NOT · a86191c6
      Arun Kuruvila authored
                      IMPLEMENTED IN ALL CLIENT PROGRAMS
      
      Description: Option "enable-cleartext-plugin" is not
      available for the following client utilities:-
      mysqldump
      mysqlimport
      mysqlshow
      mysqlcheck
      
      Analysis: The unavailability of this option limits the
      features like PAM authentication from using the above
      mentioned utilities.
      
      Fix: Option "enable-cleartext-plugin" is implemented in the
      above mentioned client utilities.
      a86191c6
    • Arun Kuruvila's avatar
      Bug #21602056 : CONCURRENT FLUSH PRIVILEGES + REVOKE/GRANT · 3846b085
      Arun Kuruvila authored
                      CRASHES IN WILD_CASE_COMPARE!
      
      Description:- Executing FLUSH PRIVILEGES and REVOKE/
      GRANT concurrently crashes the server.
      
      Analysis:- Concurrent FLUSH PRIVILEGES and REVOKE/GRANT
      might trigger a small time frame in which REVOKE/GRANT
      fetches the "acl_proxy_user" information as a part of
      "acl_check_proxy_grant_access()". Meanwhile FLUSH PRIVILEGES
      deletes the old acl structures as a part of "acl_reload()".
      After which REVOKE/GRANT tries to access the hostname in
      "wild_case_compare()" which leads to a crash because of the
      invalid memory access.
      
      Fix:- Mutex lock on "acl_cache" is acquired before fetching
      "acl_proxy_user" information in
      "acl_check_proxy_grant_access()".
      3846b085
  13. 12 Oct, 2015 1 commit
    • Mithun C Y's avatar
      Bug #20007383: HANDLE_FATAL_SIGNAL (SIG=11) IN UPDATE_REF_AND_KEYS. · f92dd6ae
      Mithun C Y authored
      Issue:
      ======
      The fulltext predicate is inside a subquery and involves
      an outer reference; it thus cannot be used for FT index look-up,
      but MySQL does not see it, which causes a illegal access.
      
      Solution:
      =========
      Solution is backported from bug#21140088. Outer reference can
      not be used as argument of the MATCH function. Added check for
      outer reference.
      f92dd6ae
  14. 08 Oct, 2015 1 commit
  15. 06 Oct, 2015 1 commit
    • Sreeharsha Ramanavarapu's avatar
      Bug #19894161: FATAL SIGNAL 11 IN · 130b5fbf
      Sreeharsha Ramanavarapu authored
                     CONVERT_CHARSET_PARTITION_CONSTANT:
                     SQL/SQL_PARTITION..CC:202
      
      Issue:
      -----
      This problem happens under the following conditions:
      1) A table partitioned with a character column as the key.
      2) The expressions specified in the partition definition
         requires a charset conversion. This can happen when the
         server's default collation is different from the
         expression's collation.
      3) INSERT DELAYED is used to insert data into the table.
      
      SOLUTION:
      ---------
      While creating the delayed_insert object, initialize it
      with the relevant select_lex.
      130b5fbf
  16. 01 Oct, 2015 1 commit
    • Sreeharsha Ramanavarapu's avatar
      Bug #19434916: FATAL_SIGNAL IN ADD_KEY_EQUAL_FIELDS() WITH · 415faa12
      Sreeharsha Ramanavarapu authored
                     UPDATE VIEW USING OUTER SUBQUERY
      
      Issue:
      -----
      While resolving a column which refers to a table/view in an
      outer query, it's respecitve item object is marked with the
      outer query's select_lex object. But when the column refers
      to a view or if the column is part of a subquery in the
      HAVING clause, an Item_ref object is created. While the
      reference to the outer query is stored by the Item_ref
      object, the same is not stored in it's real_item.
      
      This creates a problem with the IN-TO-EXISTS optmization.
      When there is an index over the column in the inner query,
      it will be considered since the column's real_item object
      will be mistaken for a local field. This will lead to a
      crash.
      
      SOLUTION:
      ---------
      Under the current design, the only way to fix this issue is
      to check the reginfo.join_tab for a NULL value. If yes, the
      query should not be worrying about the key use.
      
      The testcase and comments added as part of the fix for
      Bug#17766653 have been backported.
      415faa12
  17. 30 Sep, 2015 2 commits
  18. 22 Sep, 2015 3 commits
    • Aditya A's avatar
      Bug#20755615 CREATING INDEX ON A RENAMED COLUMN WITH CASE CRASH .FRM · ea9dbef6
      Aditya A authored
                      FILE
      
      PROBLEM
      
      In 5.5 when doing doing a rename of a column ,we ignore the case between
      old and new column names while comparing them,so if the change is just
      the case then we don't even mark the field FIELD_IS_RENAMED ,we just update
      the frm file ,but don't recreate the table as is the norm when alter is
      used.This leads to inconsistency in the innodb data dictionary which causes
      index creation to fail.
      
      FIX
      
      According to the documentation any innodb column rename should trigger
      rebuild of the table. Therefore for innodb tables we will do a strcmp()
      between the column names and if there is case change in column name
      we will trigger a rebuild.
      ea9dbef6
    • Arun Kuruvila's avatar
      Bug #21370329 : FLUSH DES_KEY_FILE MAY NOT WORK · 86375f7f
      Arun Kuruvila authored
      Description: The command FLUSH DES_KEY_FILE is expected to
      reload the DES keys from the file that was specified with
      the "--des-key-file" option at server startup. But it is not
      behaving as expected.
      
      Analysis: The des file reload is defined within a wrong
      conditional directive, rendering the command ineffective.
      Macro "OPENSSL" was used instead of "HAVE_OPENSSL" macro.
      
      Fix: "OPENSSL" macro is changed to "HAVE_OPENSSL".
      86375f7f
    • Annamalai Gurusami's avatar
      Bug #19929435 DROP DATABASE HANGS WITH MALFORMED TABLE · 8ea80ecf
      Annamalai Gurusami authored
      Note: Backporting the patch from mysql-5.6.
      
      Problem:
      
      A CREATE TABLE with an invalid table name is detected
      at SQL layer. So the table name is reset to an empty
      string.  But the storage engine is called with this
      empty table name.  The table name is specified as
      "database/table".  So, in the given scenario we get
      only "database/".
      
      Solution:
      
      Within InnoDB, detect this error and report it to
      higher layer.
      
      rb#9274 approved by jimmy.
      8ea80ecf
  19. 18 Sep, 2015 5 commits
  20. 16 Sep, 2015 1 commit
    • Shishir Jaiswal's avatar
      Bug #21467458 - UNINSTALL PLUGIN DAEMON_EXAMPLE CRASHES · 17387bc5
      Shishir Jaiswal authored
                      MYSQLD.
      
      DESCRIPTION
      ===========
      Crash occurs when daemon_example plugin is uninstalled
      immediately after its installed. This can be reproduced
      by installing and uninstalling the plugin repeatedly.
      
      ANALYSIS
      ========
      The daemon_example_plugin_deinit() function of the daemon
      example plugin calls pthread_cancel() but doesn't wait for
      the worker thread to actually complete before deallocating
      the data buffer and closing the file that it writes to.
      This is causing SEGFAULT!
      
      FIX
      ===
      Added a pthread_join() to wait for the thread to complete
      before doing the cleanup work.
      
      Removed a stray 'x' variable from the example code.
      
      NOTE
      ====
      Have made an entry in .opt file as given below:
      --plugin-dir=$DAEMONEXAMPLE_DIR
      
      This is done so that the program takes plugin directory as
      ../<dbg>/plugin/daemon_example/ instead of
      ../lib/plugin/
      17387bc5
  21. 11 Sep, 2015 1 commit
  22. 04 Sep, 2015 1 commit
    • Arun Kuruvila's avatar
      Bug #21503595 : --QUERY-ALLOC-BLOCK-SIZE=-1125899906842624 + · ddcad361
      Arun Kuruvila authored
                      PID_FILE CHECK LEADS TO OOM SIG 11
      
      Description:- A server started with 'query_alloc_block_size'
      option set to a certain range of negative values on a
      machine without enough memory may lead to OOM.
      
      Analysis:- Server uses 'strtoull()' to convert server
      variable values of type 'GET_UINT', 'GET_ULONG' or 'GET_ULL'
      from string to unsigned long long. According to the man
      page, 'strtoull()' function returns either the result of the
      conversion or, if there was a leading minus sign, the
      negation of the result of the conversion represented as an
      unsigned value, unless the original(nonnegated) value would
      overflow; in the latter case, strtoull() returns ULLONG_MAX
      and sets errno to ERANGE. So 'strtoull()' converts a small
      negative value to a larger postive value. For example string
      '-1125899906842624' will be converted to an unsigned value,
      '18445618173802708992' (ulonglong typecast of
      '-1125899906842624'). So a
      server started with 'query_alloc_block_size' set to
      "-1125899906842624" on a machine without enough memory will
      lead to OOM since server allocates '18445618173802708992'
      bytes(17178820608 GB) for query allocation block.
      
      Fix:- When server is started with any server variable, of
      type "GET_UINT", "GET_ULONG" or "GET_ULL", set to a negative
      value, a warning, "option xxx: value -yyy adjusted to zzz"
      is thrown and the value is adjusted to the lowest possible
      value for that variable. The dynamic server variable which
      is configured through the client exhibit the same behavior
      as fix made for variables configured during the server
      start up.
      ddcad361
  23. 01 Sep, 2015 2 commits
  24. 31 Aug, 2015 1 commit
  25. 26 Aug, 2015 1 commit
  26. 25 Aug, 2015 1 commit
  27. 21 Aug, 2015 1 commit
    • Arun Kuruvila's avatar
      Bug#20198490 : LOWER_CASE_TABLE_NAMES=0 ON WINDOWS LEADS TO · f4ff086a
      Arun Kuruvila authored
                     PROBLEMS
      
      Description:- Server variable "--lower_case_tables_names"
      when set to "0" on windows platform which does not support
      case sensitive file operations leads to problems. A warning
      message is printed in the error log while starting the
      server with "--lower_case_tables_names=0". Also according to
      the documentation, seting "lower_case_tables_names" to "0"
      on a case-insensitive filesystem might lead to index
      corruption.
      
      Analysis:- The problem reported in the bug is:-
      Creating an INNODB table 'a' and executing a query, "INSERT
      INTO a SELECT a FROM A;" on a server started with
      "--lower_case_tables_names=0" and running on a
      case-insensitive filesystem leads innodb to flat spin.
      Optimizer thinks that "a" and "A" are two different tables
      as the variable "lower_case_table_names" is set to "0". As a
      result, optimizer comes up with a plan which does not need a
      temporary table. If the same table is used in select and
      insert, a temporary table is needed. This incorrect
      optimizer plan leads to infinite insertions.
      
      Fix:- If the server is started with
      "--lower_case_tables_names" set to 0 on a case-insensitive
      filesystem, an error, "The server option
      'lower_case_table_names'is configured to use case sensitive
      table names but the data directory is on a case-insensitive
      file system which is an unsupported combination. Please
      consider either using a case sensitive file system for your
      data directory or switching to a case-insensitive table name
      mode.", is printed in the server error log and the server
      exits.
      f4ff086a
  28. 19 Aug, 2015 1 commit
  29. 18 Aug, 2015 2 commits
    • Shishir Jaiswal's avatar
      Bug #16171518 - LOAD XML DOES NOT HANDLE EMPTY ELEMENTS · ee02650b
      Shishir Jaiswal authored
      DESCRIPTION
      ===========
      Inability of mysql LOAD XML command to handle empty XML
      tags i.e. <row><tag/></row>. Also the behaviour is wrong
      and (different than above) when there is a space in empty
      tag i.e. <row><tag /></row>
      
      ANALYSIS
      ========
      In read_xml() the case where we encounter a close tag ('/')
      we're decreasing the 'level' blindly which is wrong.
      Actually when its an without-space-empty-tag (succeeding
      char is '>'), we need to skip the decrement. In other words
      whenever we hit a close tag ('/'), decrease the 'level'
      only when (i) It's not an (without space) empty tag i.e.
      <tag/> or, (ii) It is of format <row col="val" .../>
      
      FIX
      ===
      The switch case for '/' is modified. We've removed the
      blind decrement of 'level'. We do it only when its not an
      without-space-empty-tag. Also we are setting 'in_tag' to
      false to let program know that we're done reading current
      tag (required in the case of format <row col="val" .../>)
      ee02650b
    • Karthik Kamath's avatar
      BUG#11754258: INCORRECT ERROR MESSAGE WHEN CREATING UNSAFE · 93ac0eb1
      Karthik Kamath authored
                    VIEW
      
      
      It appears that the code refactoring done as part of the
      patch for the MySQL BUG#11749859 fixed this issue. This
      issue is not reproducible on MySQL 5.5+ versions now.
      As part of this patch, the test file "mysqldump.test" has
      been updated to remove the comment which was referring to
      the bug and also the line which suppresses the warning.
      93ac0eb1