Bug #10942 deadlock with FLUSH TABLES WITH READ LOCK + STOP SLAVE

Description:
Probably happens with 4.0 and 5.0 too.
If a client thread on slave does FLUSH TABLES WITH READ LOCK; it will prevent slave SQL thread to start next replicated statement. Then if the same client thread does STOP SLAVE, it will wait for the slave SQL thread to die but this thread is waiting for the global read lock to be gone, in order to execute its statement and _then_ die. So it's a deadlock:
SLAVE> show processlist;
+----+-------------+-----------+------+---------+------+---------------------------------+---------------------+
| Id | User        | Host      | db   | Command | Time | State                           | Info                |
+----+-------------+-----------+------+---------+------+---------------------------------+---------------------+
|  4 | root        | localhost | NULL | Query   |    3 | Killing slave                   | stop slave          |
|  6 | root        | localhost | NULL | Query   |    0 | NULL                            | show processlist    |
|  8 | system user |           | db1  | Connect |   47 | Waiting for release of readlock | create database db1 |
+----+-------------+-----------+------+---------+------+---------------------------------+---------------------+

How to repeat:
Set up replication.
slave: STOP SLAVE;
master: CREATE DATABASE db1;
slave: FLUSH TABLES WITH READ LOCK;
slave: START SLAVE; # slave SQL thread will block
slave: STOP SLAVE;

Suggested fix:
Extend this check in sql_parse.cc:
  case SQLCOM_SLAVE_STOP:
  if (thd->locked_tables || thd->active_transaction())
  {
    send_error(thd,ER_LOCK_OR_ACTIVE_TRANSACTION);
    break;
  }
by adding a "|| thd->global_read_lock" in the if().

fixed in 4.1.16 and 5.0.15

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/internals/30838

Noted in 4.1.16, 5.0.15 changelogs.