From 92d5c4d7746717488ef839b702b710cca26e5fd1 Mon Sep 17 00:00:00 2001 From: Davi Arnaut Date: Tue, 3 Jun 2008 10:59:46 -0300 Subject: 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. --- sql/sql_cache.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'sql/sql_cache.cc') 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); } -- cgit v1.2.1