To reproduce on testnet, run the following in one shell:

./src/zcashd -testnet -showmetrics=0

Wait a few seconds for validation to complete so the RPC doesn't return an error, then run the following in another shell (should block due to long-polling):

longpollid=`./src/zcash-cli -testnet getblocktemplate '{"capabilities": ["longpoll"]}' | \
python -c "import sys, json; print json.load(sys.stdin)['longpollid']"`; \
./src/zcash-cli -testnet getblocktemplate '{"capabilities": ["longpoll"], "longpollid": "'${longpollid}'"}'

In a third shell, run the following:

./src/zcash-cli -testnet stop

You should see the following error printed to console in the first shell:

zcashd: /home/jason/src/zcash/depends/x86_64-unknown-linux-gnu/share/../include/boost/thread/pthread/recursive_mutex.hpp:118: void boost::recursive_mutex::unlock(): Assertion `!pthread_mutex_unlock(&m)' failed.

Unfortunately there isn't much written to debug.log, even with maximum debug log level. All I can see is the following:

2017-07-26 15:30:57 tor: Thread interrupt
2017-07-26 15:30:57 torcontrol thread exit
2017-07-26 15:30:57 msghand thread interrupt
2017-07-26 15:30:57 addcon thread interrupt
2017-07-26 15:30:57 scheduler thread interrupt

The first time I encountered this, upon restarting zcashd, it was extremely slow and showed "Activating best chain" for tens of minutes as it re-validated the entire on-disk chain for testnet.

I believe this is because some state was not written to disk during the previous shutdown. However, I have not tried doing this again from scratch as it's a bit time-consuming, presumably it is possible to do by wiping ~/.zcash/testnet3 and performing the above steps after the full chain has been loaded. Update: verified. Chainstate is not written when this assertion error occurs.

Version: v1.0.10-1
OS/arch: Ubuntu 16.04 LTS/x86_64
Compiler: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609