This was found while tracking down
TS-3597. The assert stack is in a comment on that bug.
When you don't have a dedicated assert thread, the mutex is not locked before going into the do_io_read to process the accept event. In the dedicated thread case, you end up exercising UnixNetVConnection::acceptEvent which does grab the mutex.
May be a relatively harmless error. Since this is a newly created VC, there should be no race conditions on it. But violating locking assumptions seem like a really bad idea. Especially since grabbing a lock on a supposedly uncontended object should be cheap.
A 5.3.x patch is attached to this bug which solves the problem on my build.