- 11 Nov, 2010 3 commits
-
-
Alexander Barkov authored
-
Alexander Barkov authored
Bug#57820 extractvalue crashes Problem: ExtractValue and Replace crashed in some cases due to invalid handling of empty and NULL arguments. Per file comments: @mysql-test/r/ctype_ujis.result @mysql-test/r/xml.result @mysql-test/t/ctype_ujis.test @mysql-test/t/xml.test Adding tests @sql/item_strfunc.cc Make sure Item_func_replace::val_str safely handles empty strings. @sql/item_xmlfunc.cc set null_value if nodeset_func returned NULL, which is possible when the second argument is an unset user variable.
-
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.
-
- 08 Nov, 2010 3 commits
-
-
Sergey Glukhov authored
-
Sergey Glukhov authored
backport from 5.1
-
Sergey Glukhov authored
Problem: a flaw (derefencing a NULL pointer) in the LIKE optimization code may lead to a server crash in some rare cases. Fix: check the pointer before its dereferencing.
-
- 04 Nov, 2010 2 commits
-
-
Evgeny Potemkin authored
-
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.
-
- 03 Nov, 2010 4 commits
-
-
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.
-
karen.langford@oracle.com authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 01 Nov, 2010 5 commits
-
-
karen.langford@oracle.com authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
-
- 29 Oct, 2010 13 commits
-
-
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.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Sergey Glukhov authored
-
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.
-
Sergey Glukhov authored
-
Vasil Dimov authored
-
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.
-
- 28 Oct, 2010 2 commits
-
-
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
-
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
-
- 27 Oct, 2010 1 commit
-
-
Georgi Kodinov authored
Fixed few typos and added better wording as suggested.
-
- 29 Oct, 2010 3 commits
-
-
Vasil Dimov authored
-
Vasil Dimov authored
-
Jimmy Yang authored
-
- 28 Oct, 2010 4 commits
-
-
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
-
Mattias Jonsson authored
-
Calvin Sun authored
-
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
-