Comment 9 for bug 1258979

Appears to be a threadpool-specific race condition between some trx->mutex locking thread and Thread 1. The mutex was already unlocked by the time assert crashes:

(gdb) print mutex->lock_word
$3 = 0 '\000'

thus the other racing thread has already advanced away from trx->mutex critical section, and I don't see any of the other threads still working with trx at 0x7f0fd4000a90.

It is not clear why Thread 1 chose to call connection_abort(), i.e. which one of threadpool_process_request() and start_io() calls returned err != 0 and why.