The --hexdump option crashed mysqlbinlog when used together  
with the --read-from-remote-server option due to use of  
uninitialized memory.  
  
Since Log_event::print_header() relies on temp_buf to be  
initialized when the --hexdump option is present,  
dump_remote_log_entries() was fixed to setup temp_buf to point  
to the start of a binlog event as done in  
dump_local_log_entries().  
 
The root cause of this bug is identical to the one for 
bug #17654. The latter was fixed in 5.1 and up, so this 
patch is backport of the patches for bug #17654 to 5.0. 
 
Only 5.0 needs a changelog entry. 

1. Replace waiting of SQL thread stop by waiting of SQL error on slave and stopped
SQL thread.
2. Remove debug code because it already implemented in MTR2.

EXPLAIN EXTENDED of nested query containing a error:

   1054 Unknown column '...' in 'field list'

may cause a server crash.


Parse error like described above forces a call to
JOIN::destroy() on malformed subquery.
That JOIN::destroy function closes and frees temporary
tables. However, temporary fields of these tables
may be listed in st_select_lex::group_list of outer
query, and that st_select_lex may not cleanup them
properly. So, after the JOIN::destroy call that
st_select_lex::group_list may have Item_field
objects with dangling pointers to freed temporary
table Field objects. That caused a crash.

This patch adds corrections to the original patch
submitted 2009-04-08 (http://lists.mysql.com/commits/71607):

- fixed that the original patch didn't work because of an
  incorrect condition;
- added a test case.

my_error() was invoked in reset_slave()'s with purge_relay_logs()-failing branch
without passing sql_errno to it.

Fixed with setting sql_errno= ER_RELAY_LOG_FAIL in the purge_relay_logs()-failing branch.

into actual tree

                                    table corruption


Moved the testcase from the file myisam.test to the new testfile 
mysiam_debug.test
 

This is a "null" merge because the fix is
already in 5.1

Error happens because sp_head::MULTI_RESULTS is not set for SP
which has 'show table status' command.
The fix is to add a SQLCOM_SHOW_TABLE_STATUS case into
sp_get_flags_for_command() func.

per-file comments:
  tests/mysql_client_test.c
the test for bug 37956 isn't relevant anymore.
The query there 'select point(?,?)' doesn't produce an error.

                       
Killing the insert-select statement corrupts the MyISAM table only
when the destination table is empty and when it has indexes. When 
we bulk insert huge data and if the destination table is empty we 
disable the indexes for fast inserts, data is then inserted and 
indexes are re-enabled after bulk_insert operation
                        
Killing the query, aborts the repair table operation during enable
indexes phase leading to table corruption.
                      
We now truncate the table when we detect that enable indexes is
killed for bulk insert query.As we have an empty table before the 
operation, we can fix by truncating the table.

      
A bug in the initialization of key segment information made it point
to the wrong bit, since a bit index was used when its int value
was needed. This lead to misinterpretation of bit columns
read from MyISAM record format when a NULL bit pushed them over
a byte boundary.
Fixed by using the int value of the bit instead.

key_buffer_size.

The cause of corruption was number overflow when multiplying 
two ulong values, number of used keycache blocks with size
of a single block. The result of multiplication exceeded ulong 
range (4G) and this lead to incorrectly calculated  buffer offset
in the key cache.

The fix is to use size_t for multiplication result.

This patch also fixes pointless cast in safemalloc 
(size of allocated block to uint), that creates lot of false
alarm warnings when using big keycache (> 4GB) in debug mode.

The storage engine was not correctly handling the case in 
which rnd_pos is executed for a handler without a preceding
rnd_next or index read operation. As a result, an unitialized
file handle was sometimes being passed to the QMY_READ API.

The fix clears the rrnAssocHandle at the beginning of each
read operation and then checks to see whether it has been
set to a valid handle value before attempting to use it
in rnd_pos. If rrnAssocHandle has not been set by a previous
read operation, rnd_pos instead falls back to the use of the
currently active handle.

no conflicts