Usually this means that the Master crashed and that
sync_binlog was OFF. The solution is to
CHANGE MASTER to POS=0 of the next binlog file (see the Master) on the Slave.
The cause: The Master sends replication items to the Slave before flushing to its binlog (when
sync_binlog=OFF). If the Master crashes before the flush, the Slave has already logically moved past the end of file on the binlog. When the Master starts up again, it starts a new binlog, so CHANGEing to the beginning of that binlog is the best available solution.
A longer term solution is
sync_binlog=ON, if you can afford the extra I/O that it causes.
(If you are running with GTID, ...?)