1. 12 Aug, 2018 12 commits
  2. 09 Aug, 2018 2 commits
  3. 07 Aug, 2018 2 commits
    • Sachin's avatar
      MDEV-15127 AddressSanitizer: stack-buffer-overflow in base_list::push_back .. · 482d4da0
      Sachin authored
      Problem:-
       If we try to run this query with -WITH_ASAN=ON compiled server
        CREATE TABLE t1 (i INT);
        SET debug_dbug="+d,test_completely_invisible,test_invisible_index";
        CREATE TABLE t2 LIKE t1;
      
       This will generate a stack buffer overflow error.
        ==8922==ERROR: AddressSanitizer: stack-buffer-overflow on address #ADDR
      Analyze:-
       Error is generated on this line
             if (((*last)=new list_node(info, &end_of_list)))
       So info is our Key*, &end_of_list is global variable and last == #ADDR
       So last is suspicious variable. And last is the variable present in alter_info
       ->key_list. Now the question is how this key_list->last gets wrong/
       different stack variable. In the backtrace,  we can see that key_list is
       generated in mysql_create_table_like_table by calling
       mysql_preapre_alter_table_function and dummy key_list is created by
       mysql_create_like_table. In the end on mysql_prepare_alter_table we call
         alter_info->key_list.swap(new_key_list);
       So there is two options either key_list is empty or not empty , IF it is not
       empty then there is no issues last ptr is replaced by thd->mem_root (allocated ptr)
       So problem arises when key_list is empty. It swaps the dummy last ptr by
       mysql_prepare_alter_table declared ptr. which is wrong.
      
      Solution:-
       We wont swap variable if list does not have any element.
      482d4da0
    • Alexander Barkov's avatar
  4. 05 Aug, 2018 1 commit
  5. 04 Aug, 2018 2 commits
  6. 03 Aug, 2018 21 commits
    • Igor Babaev's avatar
      MDEV-16801 seg_fault on a query · d453374f
      Igor Babaev authored
      The bug was in the in the code of JOIN::check_for_splittable_materialized()
      where the structures describing the fields of a materialized derived
      table that potentially could be used in split optimization were build.
      As a result of this bug some fields that were not usable for splitting
      were detected as usable. This could trigger crashes further in
      st_join_table::choose_best_splitting().
      d453374f
    • Oleksandr Byelkin's avatar
      7749745b
    • Marko Mäkelä's avatar
      MDEV-16830 Crash in ALTER TABLE DROP FOREIGN KEY · aab5c557
      Marko Mäkelä authored
      ha_innobase::inplace_alter_table(): Do nothing if INNOBASE_ALTER_INSTANT
      flags (such as DROP FOREIGN KEY) was present.
      
      Also, use ALTER_OPTIONS instead of the alias ALTER_CHANGE_CREATE_OPTION.
      
      This bug was caused by MDEV-11369, MDEV-13134 or related work.
      aab5c557
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 05459706
      Marko Mäkelä authored
      05459706
    • Marko Mäkelä's avatar
      Fix heap-use-after-free in debug code · e6a808be
      Marko Mäkelä authored
      rw_lock_get_debug_info(): Remove. This function is inherently unsafe
      to use, because the copied pointers can become stale between
      rw_lock_debug_mutex_exit() and the dereferencing of the pointer in
      the caller.
      e6a808be
    • Marko Mäkelä's avatar
      Do not declare an unused variable · be370efa
      Marko Mäkelä authored
      be370efa
    • Marko Mäkelä's avatar
      7b145fae
    • Marko Mäkelä's avatar
      Fix -Wclass-memaccess warnings in InnoDB · 391e60b2
      Marko Mäkelä authored
      391e60b2
    • Marko Mäkelä's avatar
      Merge 10.1 into 10.2 · 814ae57d
      Marko Mäkelä authored
      814ae57d
    • Oleksandr Byelkin's avatar
      Disable an unstable test · 9d42eb5e
      Oleksandr Byelkin authored
      9d42eb5e
    • Marko Mäkelä's avatar
      769f6d2d
    • Marko Mäkelä's avatar
      Merge 10.0 into 10.1 · 0d3972c6
      Marko Mäkelä authored
      0d3972c6
    • Marko Mäkelä's avatar
      9dfef6e2
    • Marko Mäkelä's avatar
      Follow-up fix to MDEV-16865: InnoDB fts_query() ignores KILL · b963cbaf
      Marko Mäkelä authored
      fts_query(): Remove a redundant condition (result will never be NULL),
      and instead check if *result is NULL, to prevent SIGSEGV in
      fts_query_free_result().
      b963cbaf
    • Marko Mäkelä's avatar
      MDEV-16850 Merge new release of InnoDB 5.7.23 to 10.2 · 976f9205
      Marko Mäkelä authored
      This concludes the merge of all applicable InnoDB changes from
      MySQL 5.7.23, with the exception of a performance fix, which we
      plan to rewrite in MariaDB later in such a way that it does not
      involve changing the storage engine API:
      
      MDEV-16849 Extending indexed VARCHAR column should be instantaneous
      976f9205
    • Marko Mäkelä's avatar
      Fix a race between TRUNCATE and FOREIGN KEY check · 62ee2cd4
      Marko Mäkelä authored
      This is a port of an Oracle fix.
      
      No test case was provided by Oracle. It seems that to exploit this
      bug, one would have to SET foreign_key_checks=0 before TRUNCATE,
      and to concurrently run some DML statement that causes a foreign key
      constraint to be checked.
      
      commit 1f24c5aa2843fa548aa5c4b29c00f955e03e9f5b
      Author: Aditya A <aditya.a@oracle.com>
      Date:   Fri May 18 12:32:37 2018 +0530
      
          Bug #27208858 CONCURRENT DDL/DML ON FOREIGN KEYS CRASH IN
          PAGE_CUR_SEARCH_WITH_MATCH_BYTES
      62ee2cd4
    • Marko Mäkelä's avatar
      MDEV-14637: Fix hang due to persistent statistics · de469a2f
      Marko Mäkelä authored
      Similar to the tables SYS_FOREIGN and SYS_FOREIGN_COLS,
      the tables mysql.innodb_table_stats and mysql.innodb_index_stats
      are updated by the InnoDB internal SQL parser, which fails to
      enforce the size limits of the data. Due to this, it is possible
      for InnoDB to hang when there are persistent statistics defined on
      partitioned tables where the total length of table name,
      partition name and subpartition name exceeds the incorrectly
      defined limit VARCHAR(64). That column should have been defined
      as VARCHAR(199).
      
      btr_node_ptr_max_size(): Interpret the VARCHAR(64) as VARCHAR(199),
      to prevent a hang in the case that the upgrade script has not been
      run.
      
      dict_table_schema_check(): Ignore difference in the length of the
      table_name column.
      
      ha_innobase::max_supported_key_length(): For innodb_page_size=4k,
      return a larger value so that the table mysql.innodb_index_stats
      can be created. This could allow "impossible" tables to be created,
      such that it is not possible to insert anything into a secondary
      index when both the secondary key and the primary key are long,
      but this is the easiest and most consistent way. The Oracle fix
      would only ignore the maximum length violation for the two
      statistics tables.
      
      os_file_get_status_posix(), os_file_get_status_win32(): Handle
      ENAMETOOLONG as well.
      
      This patch is based on the following change in MySQL 5.7.23.
      Not all changes were applied, and our variant allows persistent
      statistics to work without hangs even if the table definitions
      were not upgraded.
      
      From fdbdce701ab8145ae234c9d401109dff4e4106cb Mon Sep 17 00:00:00 2001
      From: Aditya A <aditya.a@oracle.com>
      Date: Thu, 17 May 2018 16:11:43 +0530
      Subject: [PATCH] Bug #26390736 THE FIELD TABLE_NAME (VARCHAR(64)) FROM
                 MYSQL.INNODB_TABLE_STATS CAN OVERFLOW.
      
          In mysql.innodb_index_stats and mysql.innodb_table_stats
          tables the table name column didn't take into consideration
          partition names which can be more than varchar(64).
      de469a2f
    • Marko Mäkelä's avatar
      MDEV-14637: Fix hang due to DDL with FOREIGN KEY · 20460897
      Marko Mäkelä authored
      When MySQL 5.7.1 introduced WL#6326 to reduce contention on the
      non-leaf levels of B-trees, it introduced a new rw-lock mode SX
      (not conflicting with S, but conflicting with SX and X) and
      new rules to go with it.
      
      A thread that is holding an dict_index_t::lock aka index->lock
      in SX mode is permitted to acquire non-leaf buf_block_t::lock
      aka block->lock X or SX mode, in monotonically descending order.
      That is, once the thread has acquired a block->lock, it is not
      allowed to acquire a lock on its parent or grandparent pages.
      Such arbitrary-order access is only allowed when the thread
      acquired the index->lock in X mode upfront.
      
      A customer encountered a repeatable hang when loading a dump into
      InnoDB while using multiple innodb_purge_threads (default: 4).
      The dump makes very heavy use of FOREIGN KEY constraints.
      By luck, it happened so that two purge worker threads (srv_worker_thread)
      deadlocked with each other. Both were operating on the index FOR_REF
      of the InnoDB internal table SYS_FOREIGN. One of them was legitimately
      holding index->lock S-latch and the root block->lock S-latch. The other
      had acquired index->lock SX-latch, root block->lock SX-latch, and a bunch
      of other latches, including the fil_space_t::latch for freeing some blocks
      and some leaf page latches. This other thread was inside 2 nested calls
      to btr_compress() and it was trying to reacquire the root block->lock
      in X mode, violating the WL#6326 protocol.
      
      This violation led to a deadlock, because while S is compatible with SX
      and a thread can upgrade an SX lock to X when there are no conflicting
      requests, in this case there was a conflicting S lock held by the other
      purge worker thread.
      
      During this deadlock, both threads are holding dict_operation_lock S-latch,
      which would block any subsequent DDL statements, such as CREATE TABLE.
      
      The tables SYS_FOREIGN and SYS_FOREIGN_COLS are special in that they
      define key columns of the type VARCHAR(0), created using the InnoDB
      internal SQL parser. Because InnoDB does not internally enforce the
      maximum length of columns, it would happily write more than 0 bytes
      to these columns. This caused a miscalculation of node_ptr_max_size.
      
      btr_cur_will_modify_tree(): Clean up some code. (No functional change.)
      
      btr_node_ptr_max_size(): Renamed from dict_index_node_ptr_max_size().
      Use a more realistic maximum size for SYS_FOREIGN and SYS_FOREIGN_COLS.
      
      btr_cur_pessimistic_delete(): Refrain from merging pages if it is
      not safe.
      
      This work is based on the following MySQL 5.7.23 fix:
      
      commit 58dcf0b4a4165ed59de94a9a1e7d8c954f733726
      Author: Aakanksha Verma <aakanksha.verma@oracle.com>
      Date:   Wed May 9 18:54:03 2018 +0530
      
          BUG#26225783 MYSQL CRASH ON CREATE TABLE (REPRODUCEABLE) -> INNODB: A
          LONG SEMAPHORE WAIT
      20460897
    • Allen Lai's avatar
      Bug#27805553 HARD ERROR SHOULD BE REPORTED WHEN FSYNC() RETURN EIO. · f70a3185
      Allen Lai authored
      fsync() will just return EIO only once when the IO error happens, so, it's
      wrong to keep trying to call it till it return success.
      When fsync() returns EIO it should be treated as a hard error and InnoDB must
      abort immediately.
      f70a3185
    • Sergey Vojtovich's avatar
      Optimized away excessive condition · a1b23361
      Sergey Vojtovich authored
      trx_set_rw_mode() is never called for read-only transactions, this is guarded
      by callers.
      
      Removing this condition from critical section immediately gives 5% scalability
      improvement in OLTP index updates benchmark.
      a1b23361
    • Marko Mäkelä's avatar
      f867a695