fix(fill): prevent SIGSEGV from varlen vector self-alias during FILL(next) - #26608
fix(fill): prevent SIGSEGV from varlen vector self-alias during FILL(next)#26608VioletQwQ-0 wants to merge 5 commits into
Conversation
…next) When FILL(next) backfills a varlen column (VARCHAR, TEXT, etc.) across a large gap, consumeNext may call setValue with the same vector as both source and destination. The previous implementation passed w.GetBytesAt(j) directly to SetBytesAt, which can trigger BuildVarlenaNoInline -> MPool.Grow2 area reallocation before copying the source bytes. When v == w, this reallocation invalidates the source slice, causing a use-after-free SIGSEGV in memmove. This commit detects self-aliasing (v == w) in setValue's varlen branch and copies the source bytes to a temporary buffer before calling SetBytesAt, ensuring the source remains valid through any area growth. Regression coverage: - pkg/container/vector: TestSetBytesAtSelfAliasWithGrowth verifies SetBytesAt correctness under self-alias + growth at the vector layer. - pkg/sql/colexec/fill: TestSetValueSelfAliasVarlen and TestSetValueSelfAliasCrossArea verify setValue correctness for self-alias scenarios that cross area reallocation boundaries. - test/distributed/cases/function: BVT case reproduces the public 1001-row VARCHAR(256) FILL(next) materialization scenario from the issue report. Fixes matrixorigin#26558 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
The exact-head Coverage job failed at 7/11 changed statements (63.64%, required >75%). I added a deterministic mpool-exhaustion regression that executes the snapshot |
2 participants
What type of PR is this?
/kind bug
/area sql
Which issue(s) does this PR fix?
issue #26558
What this PR does / why we need it
FILL(next)can write a pending run back into the same off-heap varlen vector that supplies its next value. If a destination write grows the vector area, the source bytes can become invalid during the copy and terminate the CN.For a same-batch, non-inline varlen run,
consumeNextnow snapshots the source once into an mpool-owned off-heap vector before writing any destination row. Cross-batch and inline paths remain unchanged. The snapshot is released on append failure, set failure, and success, so the fix is bounded to one payload copy per resolved run rather than one Go allocation per row.Regression coverage
consumeNextregression uses production-shaped off-heap vectors and covers all 14 varlen OIDs accepted by the fill byte-copy path.820ee12144439c5b63c03b261f4330ec0364fdb3and passes on PR head1d82b78f6322ab44dec7560888cb39f979e136cf.a_rows/b_rows, so wrong fill direction or same-length payload corruption cannot pass.Validation
mo-cgo-test -run '^TestConsumeNextStabilizesSelfAliasedVarlenSources$' ./pkg/sql/colexec/fillmo-cgo-test ./pkg/sql/colexec/fillmo-cgo-test -race ./pkg/sql/colexec/fillgo build ./pkg/sql/colexec/fillgo vet ./pkg/sql/colexec/fillmo-servicebuild and committed SQL BVT:1001 / 256256 / 96362590929 / 1 / 1000; follow-up login/query succeededgit diff --checkmo-pr-preflight-review:PASS review=PASS validation=PENDINGmo-self-review: PASSQA decision
QA required: yes
This is an S0 user-visible CN termination fix. Keep #26558 open for QA validation after merge; the BVT is added but does not replace deployment-version verification.