1. 11 Nov, 2010 1 commit
    • Alexander Barkov's avatar
      Bug#57687 crash when reporting duplicate group_key error and utf8 · 0c4e115c
      Alexander Barkov authored
      Fixing DoS regression problem.
      
      Using "key_part->fieldnr - 1" to access the desired field
      is only correct in real INSERT queries.
      In case of inserting records into a temporary table
      when performing GROUP BY queries this expression does not work.
      
      Fix: Instead of accessing field_length and comparing it
      to key_part->length, there is an easier way to check if
      we're dealing with a prefix key: check key_part_flag against
      HA_PART_KEY_SEG flag.
      0c4e115c
  2. 04 Nov, 2010 2 commits
    • Evgeny Potemkin's avatar
      Auto-merged. · a7a1cf0d
      Evgeny Potemkin authored
      a7a1cf0d
    • Evgeny Potemkin's avatar
      Bug#57278: Crash on min/max + with date out of range. · ccbf81d5
      Evgeny Potemkin authored
      MySQL officially supports DATE values starting from 1000-01-01. This is
      enforced for int values, but not for string values, thus one
      could easily insert '0001-01-01' value. Int values are checked by
      number_to_datetime function and Item_cache_datetime::val_str uses it
      to fill MYSQL_TIME struct out of cached int value. This leads to the
      scenario where Item_cache_datetime caches a non-null datetime value and when
      it tries to convert it from int to string number_to_datetime function
      treats the value as out-of-range and returns an error and
      Item_cache_datetime::val_str returns NULL for a non-null value. Due to this
      inconsistency server crashes.
      
      Now number_to_datetime allows DATE values below 1000-01-01 if the
      TIME_FUZZY_DATE flag is set. Better NULL handling for Item_cache_datetime.
      Added the Item_cache_datetime::store function to reset str_value_cached flag
      when an item is stored.
      ccbf81d5
  3. 03 Nov, 2010 3 commits
    • Jon Olav Hauglid's avatar
      Bug #57130 crash in Item_field::print during SHOW CREATE TABLE or VIEW · 0fb0d9a9
      Jon Olav Hauglid authored
      This crash could happen if SHOW CREATE VIEW indirectly failed to open a
      view due to failures to open underlying tables (or functions). Several
      such errors were hidden and converted to ER_VIEW_INVALID warnings to
      prevent exposing details of underlying tables for which the user have
      no privileges.
      
      However, with the changes introduced by the patch for Bug#52044,
      failing to open a view will cause opened tables, views and functions
      to be closed. Since the errors causing these failures were converted
      to warnings, SHOW CREATE VIEW would try to continue. This made it
      possible to try to access memory that had been freed, causing a crash.
      
      This patch fixes the problem by not closing opened tables, views and
      functions in these cases. This allows SHOW CREATE VIEW to continue
      and also prevents it from accessing freed memory.
      
      Test case added to lock_sync.test.
      0fb0d9a9
    • Georgi Kodinov's avatar
      merge · 70d86bd1
      Georgi Kodinov authored
      70d86bd1
    • Georgi Kodinov's avatar
      merge · 1fe9a748
      Georgi Kodinov authored
      1fe9a748
  4. 01 Nov, 2010 5 commits
  5. 29 Oct, 2010 13 commits
    • Jon Olav Hauglid's avatar
      Bug #57659 Segfault in Query_cache::invalidate_data for TRUNCATE TABLE · 97e295cc
      Jon Olav Hauglid authored
      This crash could happen if TRUNCATE TABLE indirectly failed to open a
      merge table due to failures to open underlying tables. Even if opening
      failed, the TRUNCATE TABLE code would try to invalidate the table in
      the query cache. Since this table had been closed and memory released,
      this could lead to a crash.
      
      This bug was introduced by a combination of the changes introduced by
      the patch for Bug#52044, where failing to open a table will cause opened
      tables to be closed. And the changes in patch for Bug#49938, where
      TRUNCATE TABLE uses the standard open tables function.
      
      This patch fixes the problem by setting the TABLE pointer to NULL before 
      invalidating the query cache.
      
      Test case added to truncate_coverage.test.
      97e295cc
    • Georgi Kodinov's avatar
      merge · ccc6e9a8
      Georgi Kodinov authored
      ccc6e9a8
    • Georgi Kodinov's avatar
      fix tree name · 82ca4276
      Georgi Kodinov authored
      82ca4276
    • Georgi Kodinov's avatar
      merge · 97a06e4d
      Georgi Kodinov authored
      97a06e4d
    • Georgi Kodinov's avatar
      merge · 9cd91393
      Georgi Kodinov authored
      9cd91393
    • Georgi Kodinov's avatar
      merge to 5.1-security · 860c9d9c
      Georgi Kodinov authored
      860c9d9c
    • Georgi Kodinov's avatar
      merge to 5.1-security · 5ddd6c07
      Georgi Kodinov authored
      5ddd6c07
    • Georgi Kodinov's avatar
      merge to 5.0-security · db256441
      Georgi Kodinov authored
      db256441
    • Sergey Glukhov's avatar
      5.1-security->5.5-security merge · 88e82a89
      Sergey Glukhov authored
      88e82a89
    • Sergey Glukhov's avatar
      Bug#57688 Assertion `!table || (!table->write_set || bitmap_is_set(table->write_set, field · e3917c3d
      Sergey Glukhov authored
      Lines below which were added in the patch for Bug#56814 cause this crash:
      
      +      if (table->table)
      +        table->table->maybe_null= FALSE;
      
      Consider following test case:
      --
      CREATE TABLE t1(f1 INT NOT NULL);
      INSERT INTO t1 VALUES (16777214),(0);
      
      SELECT COUNT(*) FROM t1 LEFT JOIN t1 t2
      ON 1 WHERE t2.f1 > 1 GROUP BY t2.f1;
      
      DROP TABLE t1;
      --
      
      We set TABLE::maybe_null to FALSE for t2 table
      and in create_tmp_field() we create appropriate tmp table field
      using create_tmp_field_from_item() function instead of
      create_tmp_field_from_field. As a result we have
      LONGLONG field. As we have GROUP BY clause we calculate
      group buffer length, see calc_group_buffer().
      Item from group list which is used for calculation
      refer to the field from real tables and have LONG type.
      So group buffer length become insufficient for storing of
      LONGLONG value. It leads to overwriting of wrong memory
      area in do_field_int() function which is called from
      end_update().
      After some investigation I found out that
      create_tmp_field_from_item() is used only for OLAP
      grouping and can not be used for common grouping
      as it could be an incompatibility between tmp
      table fields and group buffer length.
      We can not remove create_tmp_field_from_item() call from
      create_tmp_field as OLAP needs it and we can not use this
      function for common grouping. So we should remove setting
      TABLE::maybe_null to FALSE from simplify_joins().
      In this case we'll get wrong behaviour of
      list_contains_unique_index() back. To fix it we
      could use Field::real_maybe_null() check instead of
      Field::maybe_null() and add addition check of
      TABLE_LIST::outer_join.
      e3917c3d
    • Sergey Glukhov's avatar
      5.1-security->5.5-security · bfa29d10
      Sergey Glukhov authored
      bfa29d10
    • Vasil Dimov's avatar
      Merge mysql-5.1-innodb -> mysql-5.1-bugteam · 9cff440d
      Vasil Dimov authored
      9cff440d
    • Sergey Glukhov's avatar
      Bug#57194 group_concat cause crash and/or invalid memory reads with type errors · 3a61843a
      Sergey Glukhov authored
      The problem is caused by bug49487 fix and became visible
      after after bug56679 fix.
      Items are cleaned up and set to unfixed state after filling derived table.
      So we can not rely on item::fixed state in Item_func_group_concat::print
      and we can not use 'args' array as items there may be cleaned up.
      The fix is always to use orig_args array of items as it
      always should contain the correct data.
      3a61843a
  6. 28 Oct, 2010 2 commits
    • Calvin Sun's avatar
      Bug#52062: Compiler warning in os0file.c on windows 64-bit · bc921dd7
      Calvin Sun authored
      On Windows, the parameter for number of bytes passed into WriteFile()
      and ReadFile() is DWORD. Casting is needed to silence the warning on
      64-bit Windows.
      
      Also, adding several asserts to ensure the variable for number of bytes
      is no more than 32 bits, even on 64-bit Windows.
      
      This is for InnoDB Plugin.
      
      rb://415
      Approved by: Inaam
      bc921dd7
    • Calvin Sun's avatar
      Bug#52062: Compiler warning in os0file.c on windows 64-bit · 6cc24b9a
      Calvin Sun authored
      On Windows, the parameter for number of bytes passed into WriteFile()
      and ReadFile() is DWORD. Casting is needed to silence the warning on
      64-bit Windows.
      
      Also, adding several asserts to ensure the variable for number of bytes
      is no more than 32 bits, even on 64-bit Windows.
      
      This is for built-in InnoDB.
      
      rb://415
      Approved by: Inaam
      6cc24b9a
  7. 27 Oct, 2010 1 commit
  8. 29 Oct, 2010 3 commits
  9. 28 Oct, 2010 4 commits
    • Vasil Dimov's avatar
      Fix a compilation warning: · 2aee9fb9
      Vasil Dimov authored
      /export/home/pb2/build/sb_0-2459340-1288264809.63/mysql-5.5.8-ga/storage/innobase/os/os0sync.c: In function 'os_cond_wait_timed':
      /export/home/pb2/build/sb_0-2459340-1288264809.63/mysql-5.5.8-ga/storage/innobase/os/os0sync.c:184: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'time_t'
      gmake[2]: *** [storage/innobase/CMakeFiles/innobase.dir/os/os0sync.c.o] Error 1 
      2aee9fb9
    • Mattias Jonsson's avatar
      post merge fix · 02f1a6cb
      Mattias Jonsson authored
      02f1a6cb
    • Calvin Sun's avatar
      eb3f0d2e
    • Calvin Sun's avatar
      Bug#52062: Compiler warning in os0file.c on windows 64-bit · c441f79a
      Calvin Sun authored
      On Windows, the parameter for number of bytes passed into WriteFile()
      and ReadFile() is DWORD. Casting is needed to silence the warning on
      64-bit Windows.
      
      Also, adding several asserts to ensure the variable for number of bytes
      is no more than 32 bits, even on 64-bit Windows.
      
      rb://415
      Approved by: Inaam
      c441f79a
  10. 27 Oct, 2010 6 commits