beast: Assertion failure ec == net::error::operation_aborted in websocket/impl/read.hpp

Hi, I am hitting the following assertion with a websocket client:

https://github.com/boostorg/beast/blob/develop/include/boost/beast/websocket/impl/read.hpp#L126

Looking at the called function check_stop_now it seems it can return a variety of errors, a timeout in my case. The BOOST_ASSERT macro that I am hitting makes no sense to me / I see no reason why only the operation aborted code would be expected at that place.

Version of Beast

313 (relevant code available in master too)

Steps necessary to reproduce the problem

I am having trouble extracting a minimal example due to dependencies of my application and the timeout use case requiring a suitable backend.

Hence this ticket is primarily to assure myself that this indeed /could/ be an issue in Beast.

Please let me know your thoughts so far and whether the assertion is plausible. I will gladly invest the time to build an example unless it’s something obvious and none is needed. Thank you!

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 27 (2 by maintainers)

Commits related to this issue

Remove incorrect ASSERT in websocket read fix #2264 — committed to madmongo1/beast by madmongo1 2 years ago

Most upvoted comments

We can work with this issue. I’ll post a fix as soon as I get a moment.

madmongo1 on Sep 1, 2022

I’ve just had a user report about triggering this exact assertion failure under a DOS condition (connection spam & “Too many open files” in accept) I believe I’m handling this properly as well, single thread, strands (can be configured to use multiple threads, but I can reproduce the crash with one) and only one async_read waiting for data (which never arrives since the connections are just opened and idle), no writes until a read happens

destroying the websocket stream while there is an outstanding async read or write in progress. Note that this is allowed for an Asio socket, but not for a beast websocket stream. Beast’s asynchronous operations are composed operations. They touch the websocket stream’s state multiple times before the completion handler is executed.

As in having the websocket stream object get destroyed? I’m using the shared_ptr capture technique from the examples to keep the object alive while there are operations pending

I seem have worked around it for now by not using the built-in websocket timeouts, the crash is unfortunately a bit random to trigger.

I’ve also tried to reproduce this with the async websocket example server without any luck so far.

Could one of you please explain why the timeout error “returned” by check_stop_now is not expected to happen in the read some operation? I’ve done some digging myself, but unfortunately it’s not really clear to me, maybe a comment would be helpful there? https://github.com/boostorg/beast/blob/b15a5ff0e47e72ba3d4711d2514bc65749d036ae/include/boost/beast/websocket/impl/read.hpp#L124-L128 https://github.com/boostorg/beast/blob/b15a5ff0e47e72ba3d4711d2514bc65749d036ae/include/boost/beast/websocket/impl/stream_impl.hpp#L337-L345

imerr on Sep 13, 2021