1. 24 Aug, 2012 7 commits
  2. 22 Aug, 2012 3 commits
  3. 12 Jul, 2012 1 commit
  4. 10 Jul, 2012 7 commits
    • unknown's avatar
      No commit message · dfa00930
      unknown authored
      No commit message
      dfa00930
    • Andrei Elkin's avatar
      merge from 5.1 repo. · cd0912a4
      Andrei Elkin authored
      cd0912a4
    • Andrei Elkin's avatar
      merge from 5.1 repo. · eca29d5f
      Andrei Elkin authored
      eca29d5f
    • Bjorn Munch's avatar
      86476179
    • Andrei Elkin's avatar
      merge from 5.1 repo. · 5be435de
      Andrei Elkin authored
      5be435de
    • Sujatha Sivakumar's avatar
      BUG#11762670:MY_B_WRITE RETURN VALUE IGNORED · 13f7f002
      Sujatha Sivakumar authored
      Problem:
      =======
      The return value from my_b_write is ignored by: `my_b_write_quoted',
      `my_b_write_bit',`Query_log_event::print_query_header'
      
      Most callers of `my_b_printf' ignore the return value. `log_event.cc' 
      has many calls to it. 
      
      Analysis:
      ========
      `my_b_write' is used to write data into a file. If the write fails it
      sets appropriate error number and error message through my_error()
      function call and sets the IO_CACHE::error == -1.
      `my_b_printf' function is also used to write data into a file, it
      internally invokes my_b_write to do the write operation. Upon
      success it returns number of characters written to file and on error
      it returns -1 and sets the error through my_error() and also sets
      IO_CACHE::error == -1.  Most of the event specific print functions
      for example `Create_file_log_event::print', `Execute_load_log_event::print'
      etc are the ones which make several calls to the above two functions and
      they do not check for the return value after the 'print' call. All the above 
      mentioned abuse cases deal with the client side.
      
      Fix:
      ===
      As part of bug fix a check for IO_CACHE::error == -1 has been added at 
      a very high level after the call to the 'print' function.  There are 
      few more places where the return value of "my_b_write" is ignored
      those are mentioned below.
      
      +++ mysys/mf_iocache2.c    2012-06-04 07:03:15 +0000
      @@ -430,7 +430,8 @@
                 memset(buffz, '0', minimum_width - length2);
               else
                 memset(buffz, ' ', minimum_width - length2);
      -        my_b_write(info, buffz, minimum_width - length2);
      
      +++ sql/log.cc	2012-06-08 09:04:46 +0000
      @@ -2388,7 +2388,12 @@
           {
             end= strxmov(buff, "# administrator command: ", NullS);
             buff_len= (ulong) (end - buff);
      -      my_b_write(&log_file, (uchar*) buff, buff_len);
      
      At these places appropriate return value handlers have been added.
      
      client/mysqlbinlog.cc:
        check for IO_CACHE::error == -1 has been added after the call to
        the event specific print functions
      mysys/mf_iocache2.c:
        Added handler to check the written value of `my_b_write'
      sql/log.cc:
        Added handler to check the written value of `my_b_write'
      sql/log_event.cc:
        Added error simulation statements in `Create_file_log_event::print`
        and `Execute_load_query_log_event::print'
      sql/rpl_utility.h:
        Removed the extra ';'
      13f7f002
    • Bjorn Munch's avatar
      b2131948
  5. 09 Jul, 2012 2 commits
  6. 05 Jul, 2012 2 commits
    • Andrei Elkin's avatar
      Bug#14275000 · e3c8fb4a
      Andrei Elkin authored
      Fixes for BUG11761686 left a flaw that managed to slip away from testing.
      Only effective filtering branch was actually tested with a regression test
      added to rpl_filter_tables_not_exist.
      The reason of the failure is destuction of too early mem-root-allocated memory 
      at the end of the deferred User-var's do_apply_event().
      
      Fixed with bypassing free_root() in the deferred execution branch.
      Deallocation of created in do_apply_event() items is done by the base code
      through THD::cleanup_after_query() -> free_items() that the parent Query
      can't miss.
      
      
      
      sql/log_event.cc:
        Do not call free_root() in case the deferred User-var event.
        Necessary methods to the User-var class are added, do_apply_event() refined.
      sql/log_event.h:
        Necessary methods to avoid destoying mem-root-based memory at
        User-var applying are defined.
      e3c8fb4a
    • Georgi Kodinov's avatar
      Bug #13889741: HANDLE_FATAL_SIGNAL IN _DB_ENTER_ | · 04857742
      Georgi Kodinov authored
      HANDLE_FATAL_SIGNAL IN STRNLEN
      
      Fixed the following bounds checking problems :
      1. in check_if_legal_filename() make sure the null terminated
      string is long enough before accessing the bytes in it.
      Prevents pottential read-past-buffer-end
      2. in my_wc_mb_filename() of the filename charset check
      for the end of the destination buffer before sending single
      byte characters into it.
      Prevents write-past-end-of-buffer (and garbaling stack in
      the cases reported here) errors.
      
      Added test cases.
      04857742
  7. 03 Jul, 2012 1 commit
    • Rohit Kalhans's avatar
      BUG#11762667:MYSQLBINLOG IGNORES ERRORS WHILE WRITING OUTPUT · 91c8e79f
      Rohit Kalhans authored
      This is a followup patch for the bug enabling the test
      i_binlog.binlog_mysqlbinlog_file_write.test
      this was disabled in mysql trunk and mysql 5.5 as in the release
      build mysqlbinlog was not debug compiled whereas the mysqld was.
      Since have_debug.inc script checks only for mysqld to be debug
      compiled, the test was not being skipped on release builds.
      
      We resolve this problem by creating a new inc file 
      mysqlbinlog_have_debug.inc which checks exclusively for mysqlbinlog
      to be debug compiled. if not it skips the test.
       
      
      mysql-test/include/mysqlbinlog_have_debug.inc:
        new inc file to check if mysqlbinlog is debug compiled.
      91c8e79f
  8. 29 Jun, 2012 1 commit
  9. 28 Jun, 2012 1 commit
    • Georgi Kodinov's avatar
      Bug #13708485: malformed resultset packet crashes client · 107c894a
      Georgi Kodinov authored
      Several fixes :
      
      * sql-common/client.c
      Added a validity check of the fields metadata packet sent 
      by the server.
      Now libmysql will check if the length of the data sent by
      the server matches what's expected by the protocol before
      using the data.
      
      * client/mysqltest.cc
      Fixed the error handling code in mysqltest to avoid sending
      new commands when the reading the result set failed (and 
      there are unread data in the pipe).
      
      * sql_common.h + libmysql/libmysql.c + sql-common/client.c
      unpack_fields() now generates a proper error when it fails.
      Added a new argument to this function to support the error 
      generation.
      
      * sql/protocol.cc
      Added a debug trigger to cause the server to send a NULL
      insted of the packet expected by the client for testing 
      purposes.
      107c894a
  10. 29 Jun, 2012 2 commits
  11. 28 Jun, 2012 1 commit
  12. 26 Jun, 2012 1 commit
  13. 21 Jun, 2012 1 commit
    • unknown's avatar
      Fix for LP bug#1001505 and LP bug#1001510 · 60561ae6
      unknown authored
      We set correct cmp_context during preparation to avoid changing it later by Item_field::equal_fields_propagator.
      (see mysql bugs #57135 #57692 during merging)
      60561ae6
  14. 23 Jun, 2012 1 commit
  15. 21 Jun, 2012 1 commit
  16. 20 Jun, 2012 2 commits
  17. 19 Jun, 2012 2 commits
    • Harin Vadodaria's avatar
      Bug#11753779: MAX_CONNECT_ERRORS WORKS ONLY WHEN 1ST · 61e428eb
      Harin Vadodaria authored
                    INC_HOST_ERRORS() IS CALLED.
      
      Description: Reverting patch 3755 for bug#11753779
      61e428eb
    • Igor Babaev's avatar
      Fixed bug mdev-354. · 0c69f220
      Igor Babaev authored
      Virtual columns of ENUM and SET data types were not supported properly
      in the original patch that introduced virtual columns into MariaDB 5.2.
      The problem was that for any  virtual column the patch used the 
      interval_id field of the definition of the column in the frm file as
      a reference to the virtual column expression.
      The fix stores the optional interval_id of the virtual column in the
      extended header of the virtual column expression. 
      0c69f220
  18. 18 Jun, 2012 1 commit
    • Norvald H. Ryeng's avatar
      Bug#13003736 CRASH IN ITEM_REF::WALK WITH SUBQUERIES · cac1cd88
      Norvald H. Ryeng authored
      Problem: Some queries with subqueries and a HAVING clause that
      consists only of a column not in the select or grouping lists causes
      the server to crash.
      
      During parsing, an Item_ref is constructed for the HAVING column. The
      name of the column is resolved when JOIN::prepare calls fix_fields()
      on its having clause. Since the column is not mentioned in the select
      or grouping lists, a ref pointer is not found and a new Item_field is
      created instead. The Item_ref is replaced by the Item_field in the
      tree of HAVING clauses. Since the tree consists only of this item, the
      pointer that is updated is JOIN::having. However,
      st_select_lex::having still points to the Item_ref as the root of the
      tree of HAVING clauses.
      
      The bug is triggered when doing filesort for create_sort_index(). When
      find_all_keys() calls select->cond->walk() it eventually reaches
      Item_subselect::walk() where it continues to walk the having clauses
      from lex->having. This means that it finds the Item_ref instead of the
      new Item_field, and Item_ref::walk() tries to dereference the ref
      pointer, which is still null.
      
      The crash is reproducible only in 5.5, but the problem lies latent in
      5.1 and trunk as well.
      
      Fix: After calling fix_fields on the having clause in JOIN::prepare(),
      set select_lex::having to point to the same item as JOIN::having.
      
      This patch also fixes a bug in 5.1 and 5.5 that is triggered if the
      query is executed as a prepared statement. The Item_field is created
      in the runtime arena when the query is prepared, and the pointer to
      the item is saved by st_select_lex::fix_prepare_information() and
      brought back as a dangling pointer when the query is executed, after
      the runtime arena has been reclaimed.
      
      Fix: Backport fix from trunk that switches to the permanent arena
      before calling Item_ref::fix_fields() in JOIN::prepare().
      
      
      sql/item.cc:
        Set context when creating Item_field.
      sql/sql_select.cc:
        Switch to permanent arena and update select_lex->having.
      cac1cd88
  19. 15 Jun, 2012 1 commit
  20. 14 Jun, 2012 1 commit
  21. 13 Jun, 2012 1 commit
    • Harin Vadodaria's avatar
      Bug#11753779: MAX_CONNECT_ERRORS WORKS ONLY WHEN 1ST · cf37a481
      Harin Vadodaria authored
                    INC_HOST_ERRORS() IS CALLED.
      
      Issue       : Sequence of calling inc_host_errors()
                    and reset_host_errors() required some
                    changes in order to maintain correct
                    connection error count.
      
      Solution    : Call to reset_host_errors() is shifted
                    to a location after which no calls to
                    inc_host_errors() are made.
      cf37a481