* Davi Arnaut <davi@stripped> [08/06/03 18:36]:
> 2660 Davi Arnaut 2008-06-03
> 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).
>
> === modified file 'sql/sql_cache.cc'
> --- a/sql/sql_cache.cc 2008-03-28 19:00:35 +0000
> +++ b/sql/sql_cache.cc 2008-06-03 13:59:46 +0000
> @@ -2746,7 +2746,7 @@ my_bool Query_cache::register_all_tables
> tmp++)
> unlink_table(tmp);
> }
> - return (n);
> + return test(n);
> }
This is ok to push but is there any reason to keep the return
value my_bool?
I think all such places is a time bomb, as well as my_bool type
itself.
--
