The problem was that when the slave SQL thread reads a hot relay log (hot = the one being written to by the
slave I/O thread), it must have the LOCK_log. It already took it for read_log_event(), but needs
it also for check_binlog_magic().
This should fix all recently reported failures of the rpl_max_relay_size test in 4.1 and 5.0
(though the bug exists since 4.0, it showed up first in 5.0).


sql/slave.cc:
  Fix for BUG#2011 "rare race condition producing "binlog has bad magic number" error in slave".
  The problem was that when the slave SQL thread reads a hot relay log (hot = the one being written to by the
  slave I/O thread), it must have the LOCK_log. It already took it for read_log_event(), but needs
  it also for check_binlog_magic().