Bug #17284 erroneous temp table cleanup on slave

Description:
rpl_stm_000001                 [ pass ]
slave not cooperating with mysqladmin, will try manual kill
./mysql-test-run: line 1675: kill: (30444) - No such process
slave refused to die. Sending SIGKILL
./mysql-test-run: line 1679: kill: (30444) - No such process

Cannot determine thread, fp=0x248f7c, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81d19e3
0xa6a420
0x82df125
0x82dc3be
0x82df125
0x81d5891
0xa25b80
0x97d9ce

(gdb) bt
#0  0x00a6a402 in __kernel_vsyscall ()
#1  0x00a2855f in pthread_kill () from /lib/libpthread.so.0
#2  0x082eeb3b in write_core (sig=30444) at stacktrace.c:220
#3  0x081d1a22 in handle_segfault (sig=11) at mysqld.cc:2197
#4  <signal handler called>
#5  0x08222e18 in closefrm (table=0x9b80c80, free_share=false) at table.cc:1557
#6  0x0821eebf in close_temporary (table=0x9b80c80, free_share=true, delete_table=false)
    at sql_base.cc:1460
#7  0x082dc3be in end_relay_log_info (rli=0x9b52bd0) at slave.cc:517
#8  0x082df125 in end_slave () at slave.cc:1414
#9  0x081d5891 in kill_server_thread (arg=0x656444) at mysqld.cc:879
#10 0x00a25b80 in start_thread () from /lib/libpthread.so.0
#11 0x0097d9ce in clone () from /lib/libc.so.6

How to repeat:
./mysql-test-run --force --do-test=rpl

Found that the problem is actually in cleaning temp tables in slave sql thread after
io thread reconnects to master upon slave_net_timeout elapses. 
The reason of reconnecting to steady working master is not clear though theater seems to be inside of my_real_read function.

Implementing small extension to slave/master protocol to avoid temp table cleanup
by reconnecting slave.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/4324

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/4325

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/4327

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/4496

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/4650

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/4652

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/4654

Fixed in  5.0.21, 5.1.10-beta.

Noted in 5.0.21, 5.1.10 changelogs.

Updating a field value when also requesting a lock with
<literal>GET_LOCK()</literal> would cause slave servers in a 
replication environment to terminate. (Bug #17284)

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/50009

2705 Andrei Elkin	2008-07-18
      Bug #34647 rpl_temporary discovers more than one dump thread and fails to select
      
      Many dump threads can exist due to a way the new version of mtr governs suites.
      
      For this immediate problem the test is refined not to use I_S but rather to reconnect
      explicitly with preserving logics of a an old target bug fixes verification.

changing synopsis to reflect the nature of the bug.