Bug#33362: Query cache invalidation (truncate) may hang

           if cached query uses many tables

The problem was that query cache would not properly cache
queries which used 256 or more tables but yet would leave
behind query cache blocks pointing to freed (destroyed)
data. Later when invalidating (due to a truncate) query cache
would attempt to grab a lock which resided in the freed data,
leading to hangs or undefined behavior.

This was happening due to a improper return value from the
function responsible for registering the tables used in the
query (so the cache can be invalidated later if one of the
tables is modified). The function expected a return value of
type boolean (char, 8 bits) indicating success (1) or failure
(0) but the number of tables registered (unsigned int, 32 bits)
was being returned instead. This caused the function to return
failure for cases where it had actually succeed because when
a type (unsigned int) is converted to a narrower type (char),
the excess bits on the left are discarded. Thus if the 8
rightmost bits are zero, the return value will be 0 (failure).

The solution is to simply return true (1) only if the number of
registered table is greater than zero and false (0) otherwise.

mysql-test/r/query_cache_merge.result:
  Add test case result for Bug#33362
mysql-test/t/query_cache_merge.test:
  Add test case for Bug#33362
sql/sql_cache.cc:
  Return 1 or 0 depending on the number of registered tables.

1 files changed, 1 insertions, 1 deletions

diff --git a/sql/sql_cache.cc b/sql/sql_cache.cc
index 388700f0efa..375ffc882b4 100644
--- a/sql/sql_cache.cc
+++ b/sql/sql_cache.cc
@@ -2746,7 +2746,7 @@ my_bool Query_cache::register_all_tables(Query_cache_block *block,
 	 tmp++)
       unlink_table(tmp);
   }
-  return (n);
+  return test(n);
 }