Antalya 26.6: Bump to 26.6.8

base/base/sanitizer_options.h

@@ -54,6 +54,23 @@ const char * __tsan_default_options()
 {
     return "halt_on_error=1 abort_on_error=1 history_size=7 second_deadlock_stack=1 max_allocation_size_mb=32768";
 }
+const char * __tsan_default_suppressions()
+{
+    /// The release/acquire handoff on `slot.pos` orders every access to a slot payload, so the
+    /// reports these entries suppress are not real races (see the comment in
+    /// Common/NonblockingBoundedQueue.h). A function attribute cannot suppress them, because the
+    /// element type's implicitly generated move assignment is a separate, still-instrumented
+    /// function, and the attribute additionally prevents it from being inlined.
+    ///
+    /// Only `tryPush` is listed: the `dequeue_pos` compare-exchange gives one consumer sole
+    /// ownership of a slot before the move-out in `tryPop`, so every reported pair contains the
+    /// `tryPush` write. Patterns are matched against each frame's function, file and module name,
+    /// so an unqualified name would also match the queue header's own file name, and with it the
+    /// unrelated `keeper-bench` queues. Keep them narrow: a `race:` entry also hides
+    /// heap-use-after-free reports through the frame it names.
+    return "race:^NonblockingBoundedQueue<DB::KeeperRequestForSession>::tryPush\n"
+           "race:^NonblockingBoundedQueue<DB::KeeperResponseForSession>::tryPush\n";
+}
 #endif
 
 #ifdef UNDEFINED_BEHAVIOR_SANITIZER

ci/defs/defs.py

@@ -505,6 +505,26 @@ class ArtifactNames:
 
 LLVM_FT_NUM_BATCHES = 3
 LLVM_IT_NUM_BATCHES = 5
+# Batch count of the two ASan integration-test flavors, which run the whole integration suite
+# on `AMD_MEDIUM` with three xdist workers against a two-hour pytest `--session-timeout`.
+#
+# Eight, not six: the suite measures about 112000 test-seconds, so six batches put the heaviest
+# shard at 119.7 of the 120 available minutes - no margin at all, however well they are
+# balanced - and `amd_asan_ubsan, db disk, old analyzer` timed out 133 times in the three weeks
+# after it went to six. Eight brings the heaviest shard to 82 minutes, 68% of the budget.
+#
+# Batches are the right lever rather than a longer timeout: the aggregate compute is unchanged,
+# since the work is the same and only the parallelism differs, so the only cost is one more
+# per-batch setup - and the job gets its answer 25% sooner.
+#
+# Both flavors must keep the same count: they run the same suite with the same worker count
+# against the same budget, so a count that does not fit one does not fit the other.
+#
+# To re-measure, score the packing of `get_optimal_test_batch` against per-module
+# `sum(test_duration_ms)` from CIDB rather than against its own `TEST_DURATIONS` table - that
+# table currently sums to 97000 test-seconds against a measured 112000, so it reports every
+# shard as evenly packed while the measured spread across six is 1.24.
+ASAN_IT_NUM_BATCHES = 8
 LLVM_FT_ARTIFACTS_LIST = [
     # default.profdata files for 3 batches from Stateless(Functional) tests
     ArtifactNames.LLVM_COVERAGE_FILE + f"_ft_{batch}"

ci/defs/job_configs.py

@@ -2,6 +2,7 @@
 from praktika.utils import Utils
 
 from ci.defs.defs import (
+    ASAN_IT_NUM_BATCHES,
     LLVM_ARTIFACTS_LIST,
     LLVM_FT_NUM_BATCHES,
     LLVM_IT_NUM_BATCHES,
@@ -977,15 +978,16 @@ class JobConfigs:
             requires=[ArtifactNames.DEB_AMD_RELEASE],
         ),
     )
-    # why it's master only?
+    # Despite the name, only release_branches.py uses these.
+    # `ASAN_IT_NUM_BATCHES` explains the batch count; keep it in step with the flavor below.
     integration_test_asan_master_jobs = common_integration_test_job_config.parametrize(
         *[
             Job.ParamSet(
                 parameter=f"amd_asan_ubsan, db disk, {batch}/{total_batches}",
                 runs_on=RunnerLabels.AMD_MEDIUM,
                 requires=[ArtifactNames.CH_AMD_ASAN_UBSAN_GH],
             )
-            for total_batches in (6,)
+            for total_batches in (ASAN_IT_NUM_BATCHES,)
             for batch in range(1, total_batches + 1)
         ]
     )
@@ -996,7 +998,7 @@ class JobConfigs:
                 runs_on=RunnerLabels.AMD_MEDIUM,
                 requires=[ArtifactNames.CH_AMD_ASAN_UBSAN_GH],
             )
-            for total_batches in (8,)
+            for total_batches in (ASAN_IT_NUM_BATCHES,)
             for batch in range(1, total_batches + 1)
         ],
         *[

ci/jobs/functional_tests.py

@@ -19,6 +19,23 @@
 
 temp_dir = f"{Utils.cwd()}/ci/tmp"
 
+# Substrings identifying a sanitizer build in a build type ("amd_asan_ubsan"), a
+# job parameter string ("amd_asan_ubsan, distributed plan, parallel"), or a job
+# name.
+SANITIZERS = ("asan", "tsan", "msan", "ubsan")
+
+
+def stateless_memory_limit(source):
+    """Per-test cgroup memory limit (`clickhouse-test --memory-limit`) for a run
+    identified by `source` (a build type, job-parameter string, or job name).
+
+    Sanitizer clients are memory-heavy (~500 MiB RSS each), so a test running
+    ~10 concurrent clients needs 10 GiB or the per-test cgroup OOM-kills them
+    mid-test. Every sanitizer build gets 10 GiB, others 5 GiB. Match via
+    `SANITIZERS`, not the literal `asan_ubsan` substring: the `tsan`/`msan` lanes
+    (and the private `amd_ubsan` lane, an ASan+UBSan binary) lack that substring.
+    """
+    return 10 * 2**30 if any(san in source for san in SANITIZERS) else 5 * 2**30
 
 
 class JobStages(metaclass=MetaClasses.WithIter):
@@ -98,12 +115,11 @@ def run_tests(
     if "--no-zookeeper" not in extra_args:
         extra_args += " --zookeeper"
     # Remove --report-logs-stats, it hides sanitizer errors in def reportLogStats(args): clickhouse_execute(args, "SYSTEM FLUSH LOGS")
-    # During bugfix validation the same job runs several build types, so the
-    # memory limit must follow the binary under test (`build_type`) rather than
-    # the job name. Otherwise an `amd_asan_ubsan` run gets the 5 GiB default and
-    # a master-side memory-limit failure would be inverted as a reproduced bug.
+    # Bugfix validation runs several builds per job, so size the limit from the
+    # tested `build_type` over the job name (else a master-side memory-limit
+    # failure would be inverted as a reproduced bug).
     limit_source = build_type if build_type is not None else Info().job_name
-    memory_limit = 10 * 2**30 if "asan_ubsan" in limit_source else 5 * 2**30
+    memory_limit = stateless_memory_limit(limit_source)
     # NOTE (strtgbb): Upstream appears to only monitor test memory usage on their HEAD build, let's not get distracted by OOM issues in our pipeline
     memory_limit = 10 * 2**30
     # Hand the time budget to `clickhouse-test` itself via `--global_time_limit`
@@ -966,9 +982,7 @@ def start():
                 ).set_timing(stopwatch=diag_stopwatch)
             )
         elif failed_tests:
-            memory_limit = (
-                10 * 2**30 if "asan_ubsan" in Info().job_name else 5 * 2**30
-            )
+            memory_limit = stateless_memory_limit(Info().job_name)
             diag_command = (
                 f"clickhouse-test --testname --check-zookeeper-session --hung-check"
                 f" --memory-limit {memory_limit} --trace --capture-client-stacktrace"

ci/jobs/scripts/check_style/various_checks.sh

@@ -130,7 +130,6 @@ find $ROOT_PATH/src/Functions -type f | xargs grep -l 'ContextPtr [a-z_]*;' | gr
 FUNCTIONS_WITH_CONTEXT_EXCEPTIONS=(
     # It is OK to have WithContext for derived classes from IFunctionOverloadResolver
     -e /FunctionJoinGet.cpp
-    -e /CastOverloadResolver.cpp
     -e /reverse.cpp
     -e /formatRow.cpp
     # Store global context

ci/jobs/scripts/workflow_hooks/filter_job.py

@@ -83,6 +83,8 @@ def is_ci_excluded_by_tag(job_name, tag):
 
 # Must match ci.workflows.pull_request.KEEPER_STRESS_PR_NAME
 KEEPER_STRESS_PR_NAME = "Keeper Stress Tests (PR)"
+# Provides CH_ARM_BIN_GH required by the Keeper stress job
+KEEPER_STRESS_BUILD_NAME = "Build (arm_binary)"
 
 
 def _has_keeper_stress_changes(changed_files):
@@ -281,6 +283,11 @@ def should_skip_job(job_name):
     )
     for tag in ci_exclude_tags:
         if is_ci_excluded_by_tag(job_name, tag):
+            # The Keeper stress job is not affected by exclude tags, so keep its binary build
+            if job_name == KEEPER_STRESS_BUILD_NAME and _has_keeper_stress_changes(
+                changed_files
+            ):
+                continue
             return True, f"Skipped, job name includes excluded tag '{tag}'"
 
     # If only CI scripts changed (no product code), run a minimal set of tests