Slave stopped : Could not parse relay log event entry
There are 4 possible explanations mentioned in the error message, and a fifth one that isn't mentioned.


the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), 
the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), 
a network problem, or 
a bug in the master's or slave's MySQL code. 
not mentioned in the message, it seems possible that this condition could be triggered if your slave is an older version of MySQL server than the master, particularly across versions, such as a master running 5.6.x and a slave running 5.5.x.  Slaves must almost always be the same version as the master, or newer.  When upgrading, slaves are done first, master last.


Replication involves the slave requesting a streaming copy of the master's binary log across the network, which is stored in the relay log by the slave IO thread, then executed by the slave SQL thread.

In this case, the slave SQL thread has found incomprehensible content in the relay log, and has concluded that the log was corrupt on the master, or has been corrupted on the slave, or was corrupted in transit.  TCP is "reliable" but its checksums are somewhat primitive and specific corruption patterns can go undetected.

Using CHANGE MASTER TO will discard the slave's relay logs and restart copying at the specified log position, which needs to match Execute_master_log_pos, which is where the slave SQL thread is currently pointing for its next needed event (and isn't valid).

If the log on the master is corrupt, this will not fix things, because the corrupt data will just be transferred again.  In this case, the only option will be to rebuild the slave.

Otherwise, CHANGE_MASTER_TO should remedy the problem if the fault lies in the slave'a relay log (which can be caused by having run out of disk space on the slave, under just the right conditions) or was caused by the network.

The mysqlbinlog utility can be used to validate the logs on both machines, if desired, and will be necessary on the master if you want to confirm the corruption when CHANGE_MASTER_TO doesn't fix the issue.