1. 05 Nov, 2010 1 commit
    • Bjorn Munch's avatar
      Bug #57840 MTR: parallel execution breaks with smart ordering of test cases · 0527d492
      Bjorn Munch authored
      There were actually more problems in this area:
        Slaves (if any) were unconditionally restarted, this appears unnecessary.
        Sort criteria were suboptimal, included the test name.
      Added logic to "reserve" a sequence of tests with same config for one thread
      Got rid of sort_criteria hash, put it into the test case itself
      Adds little sanity check that expected worker picks up test
      Fixed some tests that may fail if starting on running server
      Some of these fail only if *same* test is repeated.
      Finally, special sorting of tests that do --force-restart
      0527d492
  2. 21 Oct, 2010 1 commit
  3. 20 Oct, 2010 4 commits
  4. 19 Oct, 2010 3 commits
  5. 01 Oct, 2010 1 commit
  6. 30 Sep, 2010 2 commits
  7. 29 Sep, 2010 1 commit
  8. 28 Sep, 2010 1 commit
  9. 22 Sep, 2010 1 commit
  10. 21 Sep, 2010 1 commit
  11. 20 Sep, 2010 1 commit
  12. 15 Sep, 2010 1 commit
  13. 14 Sep, 2010 1 commit
  14. 10 Sep, 2010 1 commit
  15. 31 Aug, 2010 1 commit
  16. 30 Aug, 2010 2 commits
  17. 25 Aug, 2010 2 commits
  18. 19 Aug, 2010 2 commits
  19. 10 Aug, 2010 1 commit
  20. 04 Aug, 2010 2 commits
  21. 03 Aug, 2010 2 commits
  22. 02 Aug, 2010 5 commits
  23. 01 Aug, 2010 1 commit
    • Gleb Shchepa's avatar
      Bug #54461: crash with longblob and union or update with subquery · 38165ce4
      Gleb Shchepa authored
      Queries may crash, if
        1) the GREATEST or the LEAST function has a mixed list of
           numeric and LONGBLOB arguments and
        2) the result of such a function goes through an intermediate
           temporary table.
      
      An Item that references a LONGBLOB field has max_length of
      UINT_MAX32 == (2^32 - 1).
      
      The current implementation of GREATEST/LEAST returns REAL
      result for a mixed list of numeric and string arguments (that
      contradicts with the current documentation, this contradiction
      was discussed and it was decided to update the documentation).
      
      The max_length of such a function call was calculated as a
      maximum of argument max_length values (i.e. UINT_MAX32).
      
      That max_length value of UINT_MAX32 was used as a length for
      the intermediate temporary table Field_double to hold
      GREATEST/LEAST function result.
      
      The Field_double::val_str() method call on that field
      allocates a String value.
      
      Since an allocation of String reserves an additional byte
      for a zero-termination, the size of String buffer was
      set to (UINT_MAX32 + 1), that caused an integer overflow:
      actually, an empty buffer of size 0 was allocated.
      
      An initialization of the "first" byte of that zero-size
      buffer with '\0' caused a crash.
      
      The Item_func_min_max::fix_length_and_dec() has been
      modified to calculate max_length for the REAL result like
      we do it for arithmetical operators.
      
      
      ******
      Bug #54461: crash with longblob and union or update with subquery
      
      Queries may crash, if
        1) the GREATEST or the LEAST function has a mixed list of
           numeric and LONGBLOB arguments and
        2) the result of such a function goes through an intermediate
           temporary table.
      
      An Item that references a LONGBLOB field has max_length of
      UINT_MAX32 == (2^32 - 1).
      
      The current implementation of GREATEST/LEAST returns REAL
      result for a mixed list of numeric and string arguments (that
      contradicts with the current documentation, this contradiction
      was discussed and it was decided to update the documentation).
      
      The max_length of such a function call was calculated as a
      maximum of argument max_length values (i.e. UINT_MAX32).
      
      That max_length value of UINT_MAX32 was used as a length for
      the intermediate temporary table Field_double to hold
      GREATEST/LEAST function result.
      
      The Field_double::val_str() method call on that field
      allocates a String value.
      
      Since an allocation of String reserves an additional byte
      for a zero-termination, the size of String buffer was
      set to (UINT_MAX32 + 1), that caused an integer overflow:
      actually, an empty buffer of size 0 was allocated.
      
      An initialization of the "first" byte of that zero-size
      buffer with '\0' caused a crash.
      
      The Item_func_min_max::fix_length_and_dec() has been
      modified to calculate max_length for the REAL result like
      we do it for arithmetical operators.
      38165ce4
  24. 30 Jul, 2010 2 commits