beast: Possible bug in read.ipp read_some_op::operator()

In very rare cases I run into this BOOST_ASSERT:

https://github.com/boostorg/beast/blob/b4cb4f1fd3d9d1eca90f44e59e1ca0b5260d0c13/include/boost/beast/websocket/impl/read.ipp#L628

ws_.status is status::failed and I come from:

https://github.com/boostorg/beast/blob/b4cb4f1fd3d9d1eca90f44e59e1ca0b5260d0c13/include/boost/beast/websocket/impl/read.ipp#L422

ws_.status was in L422 and at the beginning of .operator() (L172) already status::failed.

I’m not completely sure it is a bug in Beast or in my own code.

Version of Beast

$ git log -1
commit b4cb4f1fd3d9d1eca90f44e59e1ca0b5260d0c13
Author: Vinnie Falco <vinnie.falco@gmail.com>
Date:   Thu Mar 22 20:14:16 2018 -0700

    Set version to 167

Steps necessary to reproduce the problem

The bug is trigged by a penetration test of my library based on Beast. I create a WebSocket Server and after that 50 threads every creating a client that connects to the server. Client and Server start to ping pong text messages and the clients a destroyed after a random time in the range of 0 to 100 ms.

This process is repeated in a loop. I run into the bug around every 10 minutes, so it is very rarely and not simple to reproduce. I hope you can give clear a statement (bug in my code or in Beast) by looking into L422 of read.ipp. If not I will provide more information how to compile and debug my code.

All relevant compiler information

$ g++ --version
g++ (GCC) 8.0.1 20180410 (experimental)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

With BOOST_ASIO_HAS_STD_CHRONO and -std=c++14.