Bug#13721076 CRASH WITH TIME TYPE/TIMESTAMP() AND WARNINGS IN SUBQUERY

The table contains one time value: '00:00:32'
This value is converted to timestamp by a subquery.

In convert_constant_item we call (*item)->is_null()
which triggers execution of the Item_singlerow_subselect subquery,
and the string "0000-00-00 00:00:32" is cached
by Item_cache_datetime.
We continue execution and call update_null_value, which calls val_int()
on the cached item, which converts the time value to ((longlong) 32)
Then we continue to do (*item)->save_in_field()
which ends up in Item_cache_datetime::val_str() which fails,
since (32 < 101) in number_to_datetime, and val_str() returns NULL.

Item_singlerow_subselect::val_str isnt prepared for this:
if exec() succeeds, and return !null_value, then val_str()
*must* succeed.

Solution: refuse to cache strings like "0000-00-00 00:00:32"
in Item_cache_datetime::cache_value, and return NULL instead.

This is similar to the solution for 
Bug#11766860 - 60085: CRASH IN ITEM::SAVE_IN_FIELD() WITH TIME DATA TYPE

This patch is for 5.5 only.
The issue is not present after WL#946, since a time value
will be converted to a proper timestamp, with the current date
rather than "0000-00-00"

1 files changed, 1 insertions, 1 deletions

diff --git a/sql/item_timefunc.cc b/sql/item_timefunc.cc
index ddb00874b62..6fc85a01668 100644
--- a/sql/item_timefunc.cc
+++ b/sql/item_timefunc.cc
@@ -2694,7 +2694,7 @@ longlong Item_datetime_typecast::val_int()
 {
   DBUG_ASSERT(fixed == 1);
   MYSQL_TIME ltime;
-  if (get_arg0_date(&ltime,1))
+  if (get_arg0_date(&ltime, TIME_FUZZY_DATE))
   {
     null_value= 1;
     return 0;