New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The beast Server Exits frequently #2859
Comments
write: The I/O operation has been aborted because of either a thread exit or an application request This error suggests you might have a lifetime issue in your application, where an I/O object (such as a socket or resolver) has been destroyed while there was an outstanding async operation. read: An existing connection was forcibly closed by the remote host
[on_write]: exception caught: bad_weak_ptr
read: An existing connection was forcibly closed by the remote host Same is the case here, it seems you tried to access a weak_ptr unconditionally while the actual object has been destroyed, my guess is you are using weak_ptr where a shared_ptr is appropriate or having a flawed object hierarchy. It's difficult to pinpoint the issue without additional details about your code. |
Thanks, @ashtum. Got it. I'll work on streamlining the code flow and share it over. It might take a little while though. Additionally, I've noticed occasionally encountering the below type of error that leads to an exit.
Thanks, |
Your server should be prepared for this kind of error (client connections might fail for all sorts of reasons). The server should close the socket and release all the resources associated with it. It seems you have a flaw in your code in that regard (either accessing a destroyed object or not checking the returned error code). |
1.84
The application I developed is frequently exiting, causing me to lose "sessions" stored in "shared_state." These sessions are crucial for the app, and such exits pose a significant problem of user's discontinuity. Although I enabled boost::stacktrace, these exits do not qualify as crashes, so it doesn't provide much help. It seems to me (with my limited knowledge) that it's a session issue between the client and server, and a typical closure of a session could potentially bring down the entire app. Perhaps, the io_context exits due to completed work.
Crash Scenario 1 and the Console message
Crash Scenario 2 and the Console message
I read this stackoverflow thread and it says "cancellation of the read invalidates future writes on the websocket.".
Given my environment being Windows, maybe leveraging Structured Exception Handling (SEH) __try and __Error could be of any help at all, nor sure of what is the right way to leverage them.
Please provide guidance to ensure stability and robustness.
Thanks, in advance!
Regards,
Tharma
The text was updated successfully, but these errors were encountered: