Thanks very much for your feedback. This has been fixed in upcoming versions and the following was noted in the 5.6.28 and 5.7.10 change logs:
On a multi-threaded slave configured with master_info_repository=TABLE and relay_log_info_repository=TABLE which had previously been run with autocommit=1, if the slave was stopped and autocommit changed to 0, executing START SLAVE caused the session to appear to hang. After the lock wait timeout, when START SLAVE proceeded the server would stop unexpectedly. The fix ensures that when master_info_repository=TABLE, relay_log_info_repository=TABLE, and autocommit=0 a new transaction is generated for start and commit to avoid deadlocks."
Upstream bug report says:
"[8 Dec 9:23] David Moss
Thanks very much for your feedback. This has been fixed in upcoming versions and the following was noted in the 5.6.28 and 5.7.10 change logs: info_repository =TABLE and relay_log_ info_repository =TABLE which had previously been run with autocommit=1, if the slave was stopped and autocommit changed to 0, executing START SLAVE caused the session to appear to hang. After the lock wait timeout, when START SLAVE proceeded the server would stop unexpectedly. The fix ensures that when master_ info_repository =TABLE, relay_log_ info_repository =TABLE, and autocommit=0 a new transaction is generated for start and commit to avoid deadlocks."
On a multi-threaded slave configured with master_
So, seems to be fixed in 5.6.28.