24.8.14 Backport of #75474 - Stricter checks when attaching/detaching threads to groups - #2016
Conversation
Stricter checks when attaching/detaching threads to groups Signed-off-by: Ilya Golshtein <igolshtein@altinity.com>
|
This is an automated comment for commit f7498e9 with description of existing statuses. It's updated for the latest CI running ❌ Click here to open a full report in a separate page
Successful checks
|
zvonand
left a comment
There was a problem hiding this comment.
LGTM, almost identical to original one.
|
@ilejn can we (you) verify it or we need attention from QA? |
It is not trivial to reproduce. I think the choice is between 'me' and 'nobody', no reasons to involve QA. |
|
AI audit note: This review comment was generated by AI (gpt-5.3-codex). Audit update for PR #2016 (thread-group attach/detach refactor and callsite migration): Confirmed defects:
Coverage summary:
|
|
@ilejn, I saw your comment. Since this PR was assigned to me, I went ahead and performed an AI-driven QA verification, focused mainly on the CI. Please find the QA Verification below — let me know if you'd like to run any further tests or validation before I add the QA Verification — ✅ ApprovedThis PR is a faithful backport of upstream #75474 (already merged upstream) and does not introduce any regression. The most relevant CI configs for a threading fix — debug build + Stress test (debug), the exact config where the original crash surfaced — passed clean, and all sanitizer builds compiled successfully. The two remaining CI failures are environmental and unrelated to this change. Summary
Evidence1. Backport fidelity (vs upstream ClickHouse#75474) 2. CI triage
3. On the AI audit note (fail-open in Note: ASAN/TSAN/MSAN/UBSAN test execution was excluded via PR options. Given the fix is upstream-validated, the backport is faithful, and debug+stress (asserts active) passed, residual risk is low. The full sanitizer matrix will run on merge. |
|
Hello @CarlosFelipeOR , thanks for the audit. The improvements are in ClickHouse#105417 and ClickHouse#106462 So I treat audit as positive. |
Changelog category (leave one):
Closes ClickHouse#59114
In https://s3.amazonaws.com/clickhouse-test-reports/74014/dcdccd54f13e74c5018f6d40e5a4caa77858dc22/stress_test__debug_.html
CurrentThread::getGroup()returned nullptr when called fromTCPHandler::processOrdinaryQuery. This means that calls toCurrentThread::attachToGroup/detachFromGroupIfNotDetachedare not properly nested: someone detached a thread that they didn't attach. (The thread is expected to be attached to a group because the caller ofprocessOrdinaryQueryholds a QueryScope for the duration of the call.)Almost all calls to
CurrentThread::attachToGroupIfDetached/detachFromGroupIfNotDetachedfollow this pattern that looks incorrect:If the thread is already attached to a group, it'll end up detached after this function returns. Normally such
thread_funcis immediately scheduled on a thread pool; then the thread shouldn't be already attached to a group (... or so I'm assuming; there were no asserts about this, so CI on this PR may prove this analysis wrong). But some code sites sometimes call such function directly, e.g.Aggregator::prepareBlocksAndFillTwoLevelImpl. AFAICT, this would incorrectly detach the thread from the thread group. I'm guessing this is what caused these test failures (but I didn't try to reproduce this and don't have an explanation for why the crash happens so rarely.)This PR replaces this pattern with a more correct one, with a bunch of asserts, wrapped in a RAII thing.
Most changes are mechanical. Most substantial ones are in
ThreadStatus.h,ThreadStatusExt.cpp, andProfileEventsExt.cpp.(ClickHouse#75474 by @al13n321)
CI/CD Options
Exclude tests:
Regression jobs to run: