Fix uncaught exception when HTTP client goes away#20981
Merged
alexey-milovidov merged 3 commits intoClickHouse:masterfrom Feb 20, 2021
Merged
Fix uncaught exception when HTTP client goes away#20981alexey-milovidov merged 3 commits intoClickHouse:masterfrom
alexey-milovidov merged 3 commits intoClickHouse:masterfrom
Conversation
Even after ClickHouse#20464 it was still possible, for example [1]. 2021.02.19 11:40:21.886191 [ 68373 ] {} <Trace> DynamicQueryHandler: Request URI: /?database=test_ds2d6y&log_comment=/usr/share/clickhouse-test/queries/0_stateless/01302_aggregate_state_exception_memory_leak.sh&enable_http_compression=1&http_zlib_compression_level=1 <snip> 2021.02.19 11:41:35.289940 [ 365 ] {} <Fatal> BaseDaemon: (version 21.3.1.6058, build id: 8D46D65205E2C8B7FE408A0B4EC76CA0483F9E92) (from thread 68373) Terminate called for uncaught exception: Code: 24, e.displayText() = DB::Exception: Cannot write to ostream at offset 262568, Stack trace (when copying this message, always include the lines below): 0. ./obj-x86_64-linux-gnu/../contrib/libcxx/include/exception:0: Poco::Exception::Exception(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int) @ 0x15b3c7db in /usr/bin/clickhouse 1. ./obj-x86_64-linux-gnu/../src/Common/Exception.cpp:56: DB::Exception::Exception(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int, bool) @ 0x8aba66e in /usr/bin/clickhouse 2. ./obj-x86_64-linux-gnu/../src/IO/WriteBufferFromOStream.cpp:0: DB::WriteBufferFromOStream::nextImpl() @ 0x8b8c105 in /usr/bin/clickhouse 3. ./obj-x86_64-linux-gnu/../src/IO/BufferBase.h:39: DB::WriteBufferFromOStream::~WriteBufferFromOStream() @ 0x8b8c537 in /usr/bin/clickhouse 4. ./obj-x86_64-linux-gnu/../src/IO/WriteBufferFromOStream.cpp:44: DB::Write [1]: https://clickhouse-test-reports.s3.yandex.net/16481/5d150cce4778dd14f58dcff67435bdec1efa155b/stress_test_(thread).html#fail1 And according to this partial stacktrace it seems that the dtor of WriteBufferFromOStream was called from WriteBufferFromHTTPServerResponse, since the class name starts from DB::Write* The problem is that if first time WriteBufferFromOStream::next() fails, it will reset position to make next write no-op, however WriteBufferFromHTTPServerResponse::next() will set position to available buffer back, and next() will throw again, but this time it can be from dtor.
robot-clickhouse
added
the
pr-bugfix
alexey-milovidov
approved these changes
Feb 19, 2021
…ing finalize())
Since I saw the following:
0. DB::WriteBufferFromOStream::nextImpl()
1. DB::WriteBufferFromHTTPServerResponse::nextImpl()
2. DB::WriteBufferFromHTTPServerResponse::finalize()
3. DB::WriteBufferFromHTTPServerResponse::~WriteBufferFromHTTPServerResponse()
4. DB::StaticRequestHandler::handleRequest(Poco::Net::HTTPServerRequest&, Poco::Net::HTTPServerResponse&)
5. Poco::Net::HTTPServerConnection::run()
6. Poco::Net::TCPServerConnection::start()
azat
force-pushed
the
http-client-reset-uncaught-exception
branch
from
da7dc98 to
1ccb333
Compare
This was referenced Feb 20, 2021
robot-clickhouse
added
pr-not-for-changelog
CheSema
reviewed
Sep 6, 2024
| } | ||
| catch (...) | ||
| { | ||
| out.finalize(); |
Member
There was a problem hiding this comment.
What did you try to achieve by it?
Member
Author
There was a problem hiding this comment.
It is hard to remember, but likely if the writeStringBinary was triggered flush, then it may throw, so we need to call finalize reset the pos so that next will be no-op (note, that cancel was not there in 2021).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
Fix uncaught exception when HTTP client goes away
Detailed description / Documentation draft:
Even after #20464 it was still possible, for example 1.
And according to this partial stacktrace it seems that the dtor of
WriteBufferFromOStream was called from
WriteBufferFromHTTPServerResponse, since the class name starts from
DB::Write*
The problem is that if first time WriteBufferFromOStream::next() fails,
it will reset position to make next write no-op, however
WriteBufferFromHTTPServerResponse::next() will set position to available
buffer back, and next() will throw again, but this time it can be from
dtor.
Refs: #19451