1. 04 Apr, 2012 1 commit
    • Sergey Glukhov's avatar
      Bug#11766300 59387: FAILING ASSERTION: CURSOR->POS_STATE == 1997660512 (BTR_PCUR_IS_POSITIONE · 17817a30
      Sergey Glukhov authored
      Bug#13639204 64111: CRASH ON SELECT SUBQUERY WITH NON UNIQUE INDEX
      The crash happened due to wrong calculation
      of key length during creation of reference for
      sort order index. The problem is that
      keyuse->used_tables can have OUTER_REF_TABLE_BIT enabled
      but used_tables parameter(create_ref_for_key() func) does
      not have it. So key parts which have OUTER_REF_TABLE_BIT
      are ommited and it could lead to incorrect key length
      calculation(zero key length).
      17817a30
  2. 21 Mar, 2012 4 commits
  3. 20 Mar, 2012 2 commits
  4. 16 Mar, 2012 1 commit
  5. 15 Mar, 2012 3 commits
    • Inaam Rana's avatar
      Bug#13825266 RACE IN LOCK_VALIDATE() WHEN ACCESSING PAGES DIRECTLY · 486e5e5a
      Inaam Rana authored
      FROM BUFFER POOL
      
      rb://975
      approved by: Marko Makela
      
      There is a race in lock_validate() where we try to access a page
      without ensuring that the tablespace stays valid during the operation
      i.e.: it is not deleted. This patch tries to fix that by using an
      existing flag (the flag is renamed to make it's name more generic
      in line with it's new use).
      486e5e5a
    • Inaam Rana's avatar
      Bug#13851171 STRING OVERFLOW IN INNODB CODE FOUND BY STATIC ANALYSIS · 8729b2e5
      Inaam Rana authored
      rb://976
      approved by: Marko Makela
      
      Add an assertion to ensure that string overflow is not happening.
      Pointed by Coverity analysis.
      8729b2e5
    • Inaam Rana's avatar
      Bug#13537504 VALGRIND: COND. JUMP/MOVE DEPENDS ON UNINITIALISED VALUES · df2da7d7
      Inaam Rana authored
      IN OS_THREAD_EQ
      
      rb://977
      approved by: Marko Makela
      
      rw_lock::writer_thread field contains the thread id of current x-holder
      or wait-x thread. This field is un-initialized at lock creation and is
      written to for the first time when an attempt is made to x-lock.
      
      Current code considers ::writer_thread as valid memory region only when
      the lock is held in x-mode (or there is an x-waiter). This is an
      overkill and it generates valgrind warnings.
      
      The fix is to consider ::writer_thread as valid memory region once it
      has been written to.
      
      Reasoning:
      ==========
      The ::writer_thread can be safely considered valid because:
      
      * We only ever do comparison with current calling threads id.
      * We only ever do comparison when ::recursive flag is set
      * We always unset ::recursive flag in x-unlock
      * Same thread cannot be unlocking and attempting to lock at the same
      time
      * thread_id recycling is not an issue because before an id is recycled
      the thread must leave innodb meaning it must release all locks meaning
      it must unset ::recursive flag.
      df2da7d7
  6. 12 Mar, 2012 6 commits
    • Luis Soares's avatar
      BUG#12400313 · 975e6708
      Luis Soares authored
      Adding missing sync_slave_with_master to the test case.
      975e6708
    • Luis Soares's avatar
      Automerge merge with latest mysql-5.1. · deb49a26
      Luis Soares authored
      deb49a26
    • Luis Soares's avatar
      BUG#12400313 · ab03c5ba
      Luis Soares authored
      Hardening the test case:
        - including a diff_tables at the end.
        - increasing the tolerance on the relay limit size.
      ab03c5ba
    • Luis Soares's avatar
      BUG#12400313 · c41a6fec
      Luis Soares authored
      Automerge with mysql-5.1.
      c41a6fec
    • Luis Soares's avatar
      BUG#12400313 RELAY_LOG_SPACE_LIMIT IS NOT WORKING IN MANY CASES · 5360c4e5
      Luis Soares authored
      BUG#64503: mysql frequently ignores --relay-log-space-limit
      
      When the SQL thread goes to sleep, waiting for more events, it sets
      the flag ignore_log_space_limit to true. This gives the IO thread a
      chance to queue some more events and ultimately the SQL thread will be
      able to purge the log once it is rotated. By then the SQL thread
      resets the ignore_log_space_limit to false. However, between the time
      the SQL thread has set the ignore flag and the time it resets it, the
      IO thread will be queuing events in the relay log, possibly going way
      over the limit.
      
      This patch makes the IO and SQL thread to synchronize when they reach
      the space limit and only ask for one event at a time. Thus the SQL
      thread sets ignore_log_space_limit flag and the IO thread resets it to
      false everytime it processes one more event. In addition, everytime
      the SQL thread processes the next event, and the limit has been
      reached, it checks if the IO thread should rotate. If it should, it
      instructs the IO thread to rotate, giving the SQL thread a chance to
      purge the logs (freeing space). Finally, this patch removes the
      resetting of the ignore_log_space_limit flag from purge_first_log,
      because this is now reset by the IO thread every time it processes the
      next event when the limit has been reached.
      
      If the SQL thread is in a transaction, it cannot purge so, there is no
      point in asking the IO thread to rotate. The only thing it can do is
      to ask for more events until the transaction is over (then it can ask
      the IO to rotate and purge the log right away). Otherwise, there would
      be a deadlock (SQL would not be able to purge and IO thread would not
      be able to queue events so that the SQL would finish the transaction).
      5360c4e5
    • Norvald H. Ryeng's avatar
      Bug#13031606 VALUES() IN A SELECT STATEMENT CRASHES SERVER · 2e72df37
      Norvald H. Ryeng authored
      Problem: Grouping results by VALUES(alias for string literal) causes
      the server to crash.
      
      Item_insert_values is not constructed to handle other types of
      arguments than field and reference to field. In this case, the
      argument is an Item_string, and this causes
      Item_insert_values::fix_fields() to crash.
      
      Fix: Issue an error message when the argument to Item_insert_values is
      not a field or a reference to a field.
      
      This is slightly in breach with documentation, which states that
      VALUES should return NULL, but the error message is only issued in
      cases where the server otherwise would crash, so there is no change in
      behavior for queries that already work. Future versions will restrict
      syntax so that using VALUES in this way is illegal.
      2e72df37
  7. 11 Mar, 2012 1 commit
  8. 09 Mar, 2012 1 commit
  9. 08 Mar, 2012 5 commits
    • Georgi Kodinov's avatar
    • Georgi Kodinov's avatar
      merge mysql-5.1->mysql-5.1-security · 8232d9a6
      Georgi Kodinov authored
      8232d9a6
    • Georgi Kodinov's avatar
      bd21f317
    • Marko Mäkelä's avatar
    • Marko Mäkelä's avatar
      Bug#13807811 BTR_PCUR_RESTORE_POSITION() CAN SKIP A RECORD · 76e064e2
      Marko Mäkelä authored
      This bug has been there at least since MySQL 4.0.9. (Before 4.0.9, the
      code probably was even more severely broken.)
      
      btr_pcur_restore_position(): When cursor restoration fails, before
      invoking btr_pcur_store_position() move to the previous or next record
      unless cursor->rel_pos==BTR_PCUR_ON or the record was not a user
      record.
      
      This bug can cause skipped records when btr_pcur_store_position() is
      called on the last record of a page. A symptom would be record count
      mismatch in CHECK TABLE, or failure to find a record to delete-mark or
      update or purge. The following operations should be affected by the
      bug:
      
      * row_search_for_mysql(): SELECT, UPDATE, REPLACE, CHECK TABLE,
        (almost anything else than INSERT)
      
      * foreign key CASCADE operations
      
      * row_merge_read_clustered_index(): index creation (since MySQL 5.1
        InnoDB Plugin)
      
      * multi-threaded purge (after MySQL 5.5): not sure, but it might fail
        to purge some records
      
      Not all callers of btr_pcur_restore_position() should be affected.
      Anything that asserts or checks that restoration succeeds is
      unaffected. For example, cursor restoration on the change buffer tree
      should always succeed, because access is being protected by additional
      latches. Likewise, rollback, or any code accesses data dictionary
      tables while holding dict_sys->mutex should be safe.
      
      rb:967 approved by Jimmy Yang
      76e064e2
  10. 06 Mar, 2012 2 commits
  11. 05 Mar, 2012 2 commits
  12. 02 Mar, 2012 2 commits
  13. 01 Mar, 2012 2 commits
  14. 29 Feb, 2012 3 commits
    • Mattias Jonsson's avatar
      merge into mysql-5.1 · bd5f062f
      Mattias Jonsson authored
      bd5f062f
    • Praveenkumar Hulakund's avatar
      Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND BREAKS REPLICATION · 892760d9
      Praveenkumar Hulakund authored
      Analysis:
      ========================
      sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input,
      instead of escape character in a string literal then sql_mode can be set to 
      "NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary 
      character like any other. 
      
      SQL_MODE set applies to the current client session. And while creating the stored 
      procedure, MySQL stores the current sql_mode and always executes the stored 
      procedure in sql_mode stored with the Procedure, regardless of the server SQL 
      mode in effect when the routine is invoked.  
      
      In the scenario (for which bug is reported), the routine is created with 
      sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode
      is "" (NOT SET) by executing statement "call testp('Axel\'s')".
      Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function)
      is considered as escape character and column "a" (of table "t1") values are 
      updated with "Axel's". The binary log generated for above update operation is as below,
      
        set sql_mode=XXXXXX (for no_backslash_escapes)
        update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci');
      
      While logging stored procedure statements, the local variables (params) used in
      statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) 
      (http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const)
      
      On slave, these logs are applied. NAME_CONST is parsed to get the variable and its
      value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode
      is also logged in. So that at slave this sql_mode is set before executing the statements
      of routine.  So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while
      parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character
      and parsing reported error for "'" (as we have only one "'" no backslash). 
      
      At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES".
      But above error reported while writing bin log, "'" (of Axel's) is escaped with
      "\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped
      while writing NAME_CONST for string variable(param, local variable) in bin log 
      irrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is 
      that logging string parameter does not take into account sql_mode value.
      
      Fix:
      ========================
      So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping  characters as 
      (n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to
      escape such characters while writing NAME_CONST for string variables in bin 
      log. 
      And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is
      represented as ''.
      http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several 
      ways to include quote characters within a string: )
      892760d9
    • Praveenkumar Hulakund's avatar
      Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND BREAKS REPLICATION · 9af695fb
      Praveenkumar Hulakund authored
      Analysis:
      ========================
      sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input,
      instead of escape character in a string literal then sql_mode can be set to 
      "NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary 
      character like any other. 
      
      SQL_MODE set applies to the current client session. And while creating the stored 
      procedure, MySQL stores the current sql_mode and always executes the stored 
      procedure in sql_mode stored with the Procedure, regardless of the server SQL 
      mode in effect when the routine is invoked.  
      
      In the scenario (for which bug is reported), the routine is created with 
      sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode
      is "" (NOT SET) by executing statement "call testp('Axel\'s')".
      Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function)
      is considered as escape character and column "a" (of table "t1") values are 
      updated with "Axel's". The binary log generated for above update operation is as below,
      
        set sql_mode=XXXXXX (for no_backslash_escapes)
        update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci');
      
      While logging stored procedure statements, the local variables (params) used in
      statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) 
      (http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const)
      
      On slave, these logs are applied. NAME_CONST is parsed to get the variable and its
      value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode
      is also logged in. So that at slave this sql_mode is set before executing the statements
      of routine.  So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while
      parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character
      and parsing reported error for "'" (as we have only one "'" no backslash). 
      
      At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES".
      But above error reported while writing bin log, "'" (of Axel's) is escaped with
      "\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped
      while writing NAME_CONST for string variable(param, local variable) in bin log 
      Airrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is 
      that logging string parameter does not take into account sql_mode value.
      
      Fix:
      ========================
      So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping  characters as 
      (n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to
      escape such characters while writing NAME_CONST for string variables in bin 
      log. 
      And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is
      represented as ''.
      http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several 
      ways to include quote characters within a string: )
      9af695fb
  15. 28 Feb, 2012 5 commits