Repository navigation
[test](be) Set the thread counts in TimeSharingTaskExecutorTest.test_invalid_task_handle_returns_error - #69915
Merged
hello-stephen merged 1 commit intoNov 1, 2026
Conversation
…invalid_task_handle_returns_error ### What problem does this PR solve? Issue Number: None Related PR: apache#65054 Problem Summary: BE UT intermittently stops with "Build stopped: CORE DUMPED" in `TimeSharingTaskExecutorTest.test_invalid_task_handle_returns_error`: AddressSanitizer reports `failed to allocate 0xfc000 (1032192) bytes ... (errno: 12)` twice and then a SEGV, and no suite after it runs. Between 2026-10-24 and 10-31 this happened in 4 of 11 sampled BE UT runs, on four different PRs; a rerun passes. Root cause: `TimeSharingTaskExecutor::ThreadConfig::max_thread_num` and `min_thread_num` have no default value. The test, added by apache#65054, sets only `thread_name` and `workload_group`, so `init()` sizes the thread pool from whatever the stack holds and keeps creating threads until mmap fails. The other ten `ThreadConfig`s in the file set both counts. Fix: set both counts to 0, as `test_remove_task_clears_queued_task_count` does. The test only calls `init()` and checks that null and foreign task handles are rejected, so it needs no worker thread. Test-only change. ### Release note None ### Check List (For Author) - Test: Unit Test - `run-be-ut.sh --run --filter='TimeSharingTaskExecutorTest.*'` on macOS arm64 (ASAN): 13 tests pass. - Behavior changed: No - Does this need documentation: No Co-Authored-By: Claude Opus 5.5 <[email protected]>
Contributor
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
Contributor
Author
|
run buildall |
Contributor
Author
|
/review |
3 of 12 tasks
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Static review completed for PR #69915 at exact head 40e7107. The two added assignments initialize the previously indeterminate ThreadConfig max/min thread counts in test_invalid_task_handle_returns_error. A 0/0 configuration is valid for this queue-only validation test: init creates no workers, start is a no-op, and stop/destruction safely quiesce the idle token. All null and invalid handle calls return from get_time_sharing_task_handle before queue submission or worker-dependent logic, so the assertions retain their intended coverage. The change is small and focused, introduces no data, concurrency, lifecycle, compatibility, error-handling, observability, or performance issue, and no parallel ThreadConfig construction remains uninitialized. No user-provided focus points were supplied. Existing inline P0/P1 findings: none. Tests were inspected but not executed under the static-only review contract.
Review converged after 1 round(s).
Contributor
TPC-H: Total hot run time: 28357 ms |
Contributor
TPC-DS: Total hot run time: 151478 ms |
Contributor
ClickBench: Total hot run time: 24.15 s |
Contributor
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
approved these changes
Nov 1, 2026
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
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.
What problem does this PR solve?
Issue Number: None
Related PR: #65054
Problem Summary:
In short:
TimeSharingTaskExecutorTest.test_invalid_task_handle_returns_errorbuilds its executor from aThreadConfigwhose thread counts are never set, so BE UT runs intermittently die in it with a core dump. This PR sets the two counts in the test.Background:
TimeSharingTaskExecutor::ThreadConfig::max_thread_numandmin_thread_numare plainintfields without a default value. The other tenThreadConfigs intime_sharing_task_executor_test.cppset both; the test added by #65054 sets onlythread_nameandworkload_groupbefore callinginit().The problem, and what it cost:
init()sizes the thread pool from whatever the stack holds. When that value is large, it keeps creating threads until mmap fails:TeamCity then reports
Build stopped: CORE DUMPED, and no suite scheduled after this test runs, so the run says nothing about the PR's own BE tests that come later. Between 2026-10-24 and 10-31 this happened in 4 of 11 sampled BE UT runs, on four different PRs (build 1087538 on #69581 is one); a rerun passes.How this PR fixes it: set
max_thread_numandmin_thread_numto 0, astest_remove_task_clears_queued_task_countin the same file does. The test only callsinit()and checks that null and foreign task handles are rejected, so it needs no worker thread. Test-only change; the executor is unchanged.Results:
Release note
None
Check List (For Author)
Test
run-be-ut.sh --run --filter='TimeSharingTaskExecutorTest.*'on macOS arm64 (ASAN): 13 tests pass.Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)