There is a crash issue.
It is caused by concurrent access of @@global.debug reader (IO thread) and a user
connection that updates the var at that time.
When @@session.debug == "", it actually points to @@global.debug. So
if client X has @@session.debug == "", and then @@global.debug is set
to "foo", then the debug symbol "foo" is active also in client X.
The slave threads always have @@session.debug == "". Hence, the slave
threads are affected by the value of @@global.debug. So if we need to
set @@global.debug but do not want it to affect the slave threads,
then we have to ensure that the slave threads are either stopped or
synced.

Fixed with modifying rpl_corruption and few other potentially vulnerable tests, adding notes
to the replication failure simulator writer.

The rule of thumb for using @@global.debug in replication thread failure simulation:
-----------------------------------------------------------------------------------
Update the variable when the slave threads or the master dump thread are down or they 
are guaranteed to stay idle e.g
in waiting for an event. Changing the value while a replication thread is UP can cause
reading a partial results of the change to end up in a crash.
For the dump thread one has to consider that a possible small hearbeat period won't break
waiting for an event in the binlog.