1. 09 Nov, 2021 2 commits
  2. 08 Nov, 2021 3 commits
  3. 04 Nov, 2021 1 commit
  4. 03 Nov, 2021 1 commit
  5. 02 Nov, 2021 2 commits
    • Aleksey Midenkov's avatar
      MDEV-22284 Aria table key read crash because wrong index used · 8ce5635a
      Aleksey Midenkov authored
      When restoring lastinx last_key.keyinfo must be updated as well. The
      good example is in _ma_check_index().
      
      The point of failure is extra(HA_EXTRA_NO_KEYREAD) in
      ha_maria::get_auto_increment():
      
        1. extra(HA_EXTRA_KEYREAD) saves lastinx;
        2. maria_rkey() changes index, so the lastinx and last_key.keyinfo;
        3. extra(HA_EXTRA_NO_KEYREAD) restores lastinx but not
           last_key.keyinfo.
      
      So we have discrepancy between lastinx and last_key.keyinfo after 3.
      8ce5635a
    • Alexander Barkov's avatar
      MDEV-24335 Unexpected question mark in the end of a TINYTEXT column · d0b611a7
      Alexander Barkov authored
      my_copy_fix_mb() passed MIN(src_length,dst_length) to
      my_append_fix_badly_formed_tail(). It could break a multi-byte
      character in the middle, which put the question mark to the
      destination.
      
      Fixing the code to pass the true src_length to
      my_append_fix_badly_formed_tail().
      d0b611a7
  6. 01 Nov, 2021 1 commit
    • Marko Mäkelä's avatar
      MDEV-26949 --debug-gdb installs redundant signal handlers · 026984c3
      Marko Mäkelä authored
      There is a server startup option --gdb a.k.a. --debug-gdb that requests
      signals to be set for more convenient debugging. Most notably, SIGINT
      (ctrl-c) will not be ignored, and you will be able to interrupt the
      execution of the server while GDB is attached to it.
      
      When we are debugging, the signal handlers that would normally display
      a terse stack trace are useless.
      
      When we are debugging with rr, the signal handlers may interfere with
      a SIGKILL that could be sent to the process by the environment, and ruin
      the rr replay trace, due to a Linux kernel bug
      https://lkml.org/lkml/2021/10/31/311
      
      To be able to diagnose bugs in kill+restart tests, we may really need
      both a trace before the SIGKILL and a trace of the failure after a
      subsequent server startup. So, we had better avoid hitting the problem
      by simply not installing those signal handlers.
      026984c3
  7. 30 Oct, 2021 2 commits
  8. 29 Oct, 2021 1 commit
    • Alexander Barkov's avatar
      MDEV-24901 SIGSEGV in fts_get_table_name, SIGSEGV in ib_vector_size, SIGSEGV... · 059797ed
      Alexander Barkov authored
      MDEV-24901 SIGSEGV in fts_get_table_name, SIGSEGV in ib_vector_size, SIGSEGV in row_merge_fts_doc_tokenize, stack smashing
      
      strmake() puts one extra 0x00 byte at the end of the string.
      The code in my_strnxfrm_tis620[_nopad] did not take this into
      account, so in the reported scenario the 0x00 byte was put outside
      of a stack variable, which made ASAN crash.
      
      This problem is already fixed in in MySQL:
      
        commit 19bd66fe43c41f0bde5f36bc6b455a46693069fb
        Author: bin.x.su@oracle.com <>
        Date:   Fri Apr 4 11:35:27 2014 +0800
      
      But the fix does not seem to be correct, as it breaks when finds a zero byte
      in the source string.
      
      Using memcpy() instead of strmake().
      
      - Unlike strmake(), memcpy() it does not write beyond the destination
        size passed.
      - Unlike the MySQL fix, memcpy() does not break on the first 0x00 byte found
        in the source string.
      059797ed
  9. 28 Oct, 2021 5 commits
  10. 27 Oct, 2021 3 commits
    • Sergei Petrunia's avatar
      Fix compile warning: · 3a9967d7
      Sergei Petrunia authored
      ha_rocksdb.h:459:15: warning: 'table_type' overrides a member
      function but is not marked 'override' [-Winconsistent-missing-override]
      3a9967d7
    • Alexander Barkov's avatar
      MDEV-25402 Assertion `!str || str != Ptr' failed in String::copy · 2ed148c8
      Alexander Barkov authored
      The assert inside String::copy() prevents copying from from "str"
      if its own String::Ptr also points to the same memory.
      
      The idea of the assert is that copy() performs memory reallocation,
      and this reallocation can free (and thus invalidate) the memory pointed by Ptr,
      which can lead to further copying from a freed memory.
      
      The assert was incomplete: copy() can free the memory pointed by its Ptr
      only if String::alloced is true!
      
      If the String is not alloced, it is still safe to copy even from
      the location pointed by Ptr.
      
      This scenario demonstrates a safe copy():
        const char *tmp= "123";
        String str1(tmp, 3);
        String str2(tmp, 3);
        // This statement is safe:
        str2.copy(str1->ptr(), str1->length(), str1->charset(), cs_to, &errors);
      
      Inside the copy() the parameter "str" is equal to String::Ptr in this example.
      But it's still ok to reallocate the memory for str2, because str2
      was a constant before the copy() call. Thus reallocation does not
      make the memory pointed by str1->ptr() invalid.
      
      Adjusting the assert condition to allow copying for constant strings.
      2ed148c8
    • Marko Mäkelä's avatar
      Fix tests for PLUGIN_PARTITION=NO · 4b8340d8
      Marko Mäkelä authored
      4b8340d8
  11. 26 Oct, 2021 6 commits
  12. 25 Oct, 2021 4 commits
  13. 22 Oct, 2021 1 commit
  14. 21 Oct, 2021 8 commits