The issue of the current bug is unguarded access to mi->slave_running 
by the shutdown thread calling end_slave() that is bug#29968 
(alas happened not to be cross-linked with the current bug)

Fixed:

with removing the unguarded read of the running status
and perform reading it in terminate_slave_thread()
at time run_lock is taken (mostly bug#29968 backporting, still with some
improvements over that patch - see the error reporting from 
terminate_slave_thread()).
Issue of bug#38716 is fixed here for 5.0 branch as well.

Note:

There has been a separate artifact identified - 
a race condition between init_slave() and  end_slave() - 
reported as  Bug#44467.