1. 21 Aug, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug #46456 [Ver->Prg]: HANDLER OPEN + TRUNCATE + DROP · f59400f4
      Ramil Kalimullin authored
      (temporary) TABLE, crash
      
      Problem: if one has an open "HANDLER t1", further "TRUNCATE t1" 
      doesn't close the handler and leaves handler table hash in an 
      inconsistent state, that may lead to a server crash.
      
      Fix: TRUNCATE should implicitly close all open handlers.
      
      Doc. request: the fact should be described in the manual accordingly.
      f59400f4
  2. 20 Aug, 2009 1 commit
  3. 19 Aug, 2009 2 commits
    • Georgi Kodinov's avatar
      Bug #46019: ERROR 1356 When selecting from within another · 4207e50e
      Georgi Kodinov authored
      view that has Group By
            
      Table access rights checking function check_grant() assumed
      that no view is opened when it's called.
      This is not true with nested views where the inner view
      needs materialization. In this case the view is already 
      materialized when check_grant() is called for it.
      This caused check_grant() to not look for table level
      grants on the materialized view table.
      Fixed by checking if a view is already materialized and if 
      it is check table level grants using the original table name
      (not the ones of the materialized temp table).
      4207e50e
    • Georgi Kodinov's avatar
      0c8690e5
  4. 17 Aug, 2009 1 commit
  5. 13 Aug, 2009 1 commit
    • Davi Arnaut's avatar
      Bug#46013: rpl_extraColmaster_myisam fails on pb2 · 97dbd987
      Davi Arnaut authored
      Bug#45243: crash on win in sql thread clear_tables_to_lock() -> free()
      Bug#45242: crash on win in mysql_close() -> free()
      Bug#45238: rpl_slave_skip, rpl_change_master failed (lost connection) for STOP SLAVE
      Bug#46030: rpl_truncate_3innodb causes server crash on windows
      Bug#46014: rpl_stm_reset_slave crashes the server sporadically in pb2
      
      When killing a user session on the server, it's necessary to
      interrupt (notify) the thread associated with the session that
      the connection is being killed so that the thread is woken up
      if waiting for I/O. On a few platforms (Mac, Windows and HP-UX)
      where the SIGNAL_WITH_VIO_CLOSE flag is defined, this interruption
      procedure is to asynchronously close the underlying socket of
      the connection.
      
      In order to enable this schema, each connection serving thread
      registers its VIO (I/O interface) so that other threads can
      access it and close the connection. But only the owner thread of
      the VIO might delete it as to guarantee that other threads won't
      see freed memory (the thread unregisters the VIO before deleting
      it). A side note: closing the socket introduces a harmless race
      that might cause a thread attempt to read from a closed socket,
      but this is deemed acceptable.
      
      The problem is that this infrastructure was meant to only be used
      by server threads, but the slave I/O thread was registering the
      VIO of a mysql handle (a client API structure that represents a
      connection to another server instance) as a active connection of
      the thread. But under some circumstances such as network failures,
      the client API might destroy the VIO associated with a handle at
      will, yet the VIO wouldn't be properly unregistered. This could
      lead to accesses to freed data if a thread attempted to kill a
      slave I/O thread whose connection was already broken.
      
      There was a attempt to work around this by checking whether
      the socket was being interrupted, but this hack didn't work as
      intended due to the aforementioned race -- attempting to read
      from the socket would yield a "bad file descriptor" error.
      
      The solution is to add a hook to the client API that is called
      from the client code before the VIO of a handle is deleted.
      This hook allows the slave I/O thread to detach the active vio
      so it does not point to freed memory.
      97dbd987
  6. 12 Aug, 2009 1 commit
    • 's avatar
      BUG#45516 SQL thread does not use database charset properly · f5be2159
      authored
              
      Replication SQL thread does not set database default charset to 
      thd->variables.collation_database properly, when executing LOAD DATA binlog.
      This bug can be repeated by using "LOAD DATA" command in STATEMENT mode.
              
      This patch adds code to find the default character set of the current database 
      then assign it to thd->db_charset when slave server begins to execute a relay log.
      The test of this bug is added into rpl_loaddata_charset.test 
      f5be2159
  7. 11 Aug, 2009 4 commits
  8. 10 Aug, 2009 2 commits
  9. 08 Aug, 2009 1 commit
    • Davi Arnaut's avatar
      Bug#45010: invalid memory reads during parsing some strange statements · 69fbbdc1
      Davi Arnaut authored
      The problem is that the lexer could inadvertently skip over the
      end of a query being parsed if it encountered a malformed multibyte
      character. A specially crated query string could cause the lexer
      to jump up to six bytes past the end of the query buffer. Another
      problem was that the laxer could use unfiltered user input as
      a signed array index for the parser maps (having upper and lower
      bounds 0 and 256 respectively).
      
      The solution is to ensure that the lexer only skips over well-formed
      multibyte characters and that the index value of the parser maps
      is always a unsigned value.
      69fbbdc1
  10. 06 Aug, 2009 1 commit
  11. 04 Aug, 2009 2 commits
  12. 03 Aug, 2009 2 commits
  13. 02 Aug, 2009 1 commit
    • Alfranio Correia's avatar
      BUG#43264 Test rpl_trigger is failing randomly w/ use of copy_file in 5.0 · 407520b6
      Alfranio Correia authored
      The test case fails sporadically on Windows while trying to overwrite an unused
      binary log. The problem stems from the fact that MySQL on Windows does not
      immediately unlock/release a file while the process that opened and closed it is
      still running. In BUG 38603, this issue was circumvented by stopping the MySQL
      process, copying the file and then restarting the MySQL process. 
      
      Unfortunately, such facilities are not available in the 5.0.  Other approaches
      such as stopping the slave and issuing change master do not work because the relay
      log file and index are not closed when a slave is stopped. So to fix the problem,
      we simply don't run on windows the part of the test that was failing.
      407520b6
  14. 31 Jul, 2009 1 commit
  15. 30 Jul, 2009 4 commits
  16. 28 Jul, 2009 2 commits
    • Alexey Kopytov's avatar
      Automerge. · 8e9b79ca
      Alexey Kopytov authored
      8e9b79ca
    • Alexey Kopytov's avatar
      Bug #45031: invalid memory reads in my_real_read using protocol · 53434623
      Alexey Kopytov authored
                  compression 
       
      Since uint3korr() may read 4 bytes depending on build flags and 
      platform, allocate 1 extra "safety" byte in the network buffer 
      for cases when uint3korr() in my_real_read() is called to read
      last 3 bytes in the buffer. 
       
      It is practically hard to construct a reliable and reasonably 
      small test case for this bug as that would require constructing 
      input stream such that a certain sequence of bytes in a 
      compressed packet happens to be the last 3 bytes of the network 
      buffer. 
      53434623
  17. 27 Jul, 2009 3 commits
    • Davi Arnaut's avatar
      Bug#46385: [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted t · 71713f32
      Davi Arnaut authored
      The maximum value of the max_join_size variable is set by converting
      a signed type (long int) with negative value (-1) to a wider unsigned
      type (unsigned long long), which yields the largest possible value of
      the wider unsigned type -- as per the language conversion rules. But,
      depending on build options, the type of the max_join_size might be a
      shorter type (ha_rows - unsigned long) which causes the warning to be
      thrown once the large value is truncated to fit.
      
      The solution is to ensure that the maximum value of the variable is
      always set to the maximum value of integer type of max_join_size.
      
      Furthermore, it would be interesting to always have a fixed type for
      this variable, but this would incur in a change of behavior which is
      not acceptable for a GA version. See Bug#35346.
      71713f32
    • Davi Arnaut's avatar
      Bug#20023: mysql_change_user() resets the value of SQL_BIG_SELECTS · 93bd65b0
      Davi Arnaut authored
      Post-merge fix: test case could fail due to a conversion of the
      max_join_size value to a integer. Fixed by preserving the value
      as a string for comparison purposes.
      93bd65b0
    • Satya B's avatar
      merging with mysql-5.0-bugteam · a8465f48
      Satya B authored
      a8465f48
  18. 24 Jul, 2009 5 commits
    • Gleb Shchepa's avatar
      Bug #38816: kill + flush tables with read lock + stored · 6aea4ceb
      Gleb Shchepa authored
                  procedures causes crashes!
      
      The problem of that bugreport was mostly fixed by the
      patch for bug 38691.
      However, attached test case focused on another crash or
      valgrind warning problem: SHOW PROCESSLIST query accesses
      freed memory of SP instruction that run in a parallel
      connection.
      
      Changes of thd->query/thd->query_length in dangerous
      places have been guarded with the per-thread
      LOCK_thd_data mutex (the THD::LOCK_delete mutex has been
      renamed to THD::LOCK_thd_data).
      6aea4ceb
    • Alexey Kopytov's avatar
      Automerge. · ec7ea445
      Alexey Kopytov authored
      ec7ea445
    • Alexey Kopytov's avatar
      Bug #46075: Assertion failed: 0, file .\protocol.cc, line 416 · c76f98a5
      Alexey Kopytov authored
      In create_myisam_from_heap() mark all errors as fatal except 
      HA_ERR_RECORD_FILE_FULL for a HEAP table.
      
      Not doing so could lead to problems, e.g. in a case when a
      temporary MyISAM table gets overrun due to its MAX_ROWS limit
      while executing INSERT/REPLACE IGNORE ... SELECT. 
      The SELECT execution was aborted, but the error was 
      converted to a warning due to IGNORE clause, so neither 'ok' 
      nor 'error' packet could be sent back to the client. This 
      condition led to hanging client when using 5.0 server, or 
      assertion failure in 5.1.
      c76f98a5
    • V Narayanan's avatar
      merging with mysql-5.0-bugteam · f20dd864
      V Narayanan authored
      f20dd864
    • Satya B's avatar
      merge to mysql-5.0-bugteam · 4465e301
      Satya B authored
      4465e301
  19. 23 Jul, 2009 1 commit
    • Staale Smedseng's avatar
      Bug #45770 errors reading server SSL files are printed, but · 63ab8415
      Staale Smedseng authored
      not logged
              
      Errors encountered during initialization of the SSL subsystem
      are printed to stderr, rather than to the error log.
              
      This patch adds a parameter to several SSL init functions to
      report the error (if any) out to the caller. The function
      init_ssl() in mysqld.cc is moved after the initialization of
      the log subsystem, so that any error messages can be logged to
      the error log. Printing of messages to stderr has been 
      retained to get diagnostic output in a client context.
      63ab8415
  20. 21 Jul, 2009 4 commits
    • MySQL Build Team's avatar
      Backport into build-200907211706-5.0.82sp1 · a734d03c
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2792
      > revision-id: sergey.glukhov@sun.com-20090703083500-jq8vhw0tqr37j7te
      > parent: bernt.johnsen@sun.com-20090703083610-o7l4s8syz05rc4w0
      > committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
      > branch nick: mysql-5.0-bugteam
      > timestamp: Fri 2009-07-03 13:35:00 +0500
      > message:
      >   Bug#45806 crash when replacing into a view with a join!
      >   The crash happend because for views which are joins
      >   we have table_list->table == 0 and 
      >   table_list->table->'any method' call leads to crash.
      >   The fix is to perform table_list->table->file->extra()
      >   method for all tables belonging to view.
      a734d03c
    • MySQL Build Team's avatar
      Backport into build-200907211706-5.0.82sp1 · 4461edde
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2772
      > revision-id: joro@sun.com-20090615133815-eb007p5793in33p5
      > parent: joro@sun.com-20090612140659-4hj1tta9p8wvcw4k
      > committer: Georgi Kodinov <joro@sun.com>
      > branch nick: B44810-5.0-bugteam
      > timestamp: Mon 2009-06-15 16:38:15 +0300
      > message:
      >   Bug #44810: index merge and order by with low sort_buffer_size
      >   crashes server!
      >   
      >   The problem affects the scenario when index merge is followed by a filesort
      >   and the sort buffer is not big enough for all the sort keys.
      >   In this case the filesort function will read the data to the end through the 
      >   index merge quick access method (and thus closing the cursor etc), 
      >   but will leave the pointer to the quick select method in place.
      >   It will then create a temporary file to hold the results of the filesort and
      >   will add it as a sort output file (in sort.io_cache).
      >   Note that filesort will copy the original 'sort' structure in an automatic
      >   variable and restore it after it's done.
      >   As a result at exiting filesort() we have a sort.io_cache filled in and 
      >   nothing else (as a result of close of the cursors at end of reading data 
      >   through index merge).
      >   Now create_sort_index() will note that there is a select and will clean it up
      >   (as it's been used already by filesort() reading the data in). While doing that
      >   a special case in the index merge destructor will clean up the sort.io_cache,
      >   assuming it's an output of the index merge method and is not needed anymore.
      >   As a result the code that tries to read the data back from the filesort output 
      >   will get no data in both memory and disk and will crash.
      >         
      >   Fixed similarly to how filesort() does it : by copying the sort.io_cache structure
      >   to a local variable, removing the pointer to the io_cache (so that it's not freed 
      >   by QUICK_INDEX_MERGE_SELECT::~QUICK_INDEX_MERGE_SELECT) and restoring the original 
      >   structure (together with the valid pointer) after the cleanup is done.
      >   This is a safe thing to do because all the structures are already cleaned up by
      >   hitting the end of the index merge's read method (QUICK_INDEX_MERGE_SELECT::get_next()) 
      >   and the cleanup code being written in a way that tolerates repeating cleanups.
      4461edde
    • MySQL Build Team's avatar
      Backport into build-200907211706-5.0.82sp1 · 57a171a7
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2763
      > revision-id: sergey.glukhov@sun.com-20090602063813-33mh88cz5vpa2jqe
      > parent: alexey.kopytov@sun.com-20090601124224-zgt3yov9wou590e9
      > committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
      > branch nick: mysql-5.0-bugteam
      > timestamp: Tue 2009-06-02 11:38:13 +0500
      > message:
      >   Bug#45152 crash with round() function on longtext column in a derived table
      >   The crash happens due to wrong max_length value which is set on
      >   Item_func_round::fix_length_and_dec() stage. The value is set to
      >   args[0]->max_length which is too big in case of LONGTEXT(LONGBLOB) fields.
      >   The fix is to set max_length using float_length() function.
      57a171a7
    • MySQL Build Team's avatar
      Backport into build-200907211706-5.0.82sp1 · 2cf7f53b
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2733
      > revision-id: gshchepa@mysql.com-20090430192037-9p1etcynkglte2j3
      > parent: aelkin@mysql.com-20090430143246-zfqaz0t7uoluzdz2
      > committer: Gleb Shchepa <gshchepa@mysql.com>
      > branch nick: mysql-5.0-bugteam
      > timestamp: Fri 2009-05-01 00:20:37 +0500
      > message:
      >   Bug #37362: Crash in do_field_eq
      >   
      >   EXPLAIN EXTENDED of nested query containing a error:
      >   
      >      1054 Unknown column '...' in 'field list'
      >   
      >   may cause a server crash.
      >   
      >   
      >   Parse error like described above forces a call to
      >   JOIN::destroy() on malformed subquery.
      >   That JOIN::destroy function closes and frees temporary
      >   tables. However, temporary fields of these tables
      >   may be listed in st_select_lex::group_list of outer
      >   query, and that st_select_lex may not cleanup them
      >   properly. So, after the JOIN::destroy call that
      >   st_select_lex::group_list may have Item_field
      >   objects with dangling pointers to freed temporary
      >   table Field objects. That caused a crash.
      2cf7f53b