heguanhui opened a new pull request, #64188:
URL: https://github.com/apache/doris/pull/64188
### What problem does this PR solve?
Issue Number: close #64187
Related PR: #
Problem Summary:
When running BE UT with `CMAKE_BUILD_TYPE=LSAN` on ARM64 architecture, the
test cases `IntersectOperatorTest::test_sink_large_string_data_over_4g` and
`ExceptOperatorTest::test_sink_large_string_data_over_4g` crash the entire UT
process with:
```
==15521==ERROR: LeakSanitizer: requested allocation size 0x200000000 exceeds
maximum supported size of 0x100000000
```
**Root cause:**
1. **LSAN ARM64 allocation limit**: In LSAN source code
(`compiler-rt/lib/lsan/lsan_allocator.cpp`), the maximum allowed single
allocation size is defined per architecture:
```cpp
#if defined(__i386__) || defined(__arm__)
static const uptr kMaxAllowedMallocSize = 1ULL << 30; // 1GB
#elif defined(__mips64) || defined(__aarch64__)
static const uptr kMaxAllowedMallocSize = 4ULL << 30; // 4GB (ARM64)
#else
static const uptr kMaxAllowedMallocSize = 1ULL << 40; // 1TB (x86_64)
#endif
```
On ARM64 (`__aarch64__`), `kMaxAllowedMallocSize = 0x100000000` (4GB). Any
single allocation exceeding this limit triggers a fatal error.
2. **PODArray power-of-two rounding**: `PODArrayBase::reserve()` rounds up
the requested size to the next power of two via
`round_up_to_power_of_two_or_zero()`. When the test accumulates ~4.1GB of
string data in `ColumnStr::chars`, the resize request gets rounded up to **8GB
(0x200000000)**, which exceeds LSAN's 4GB limit on ARM64.
| Batch | chars.size() | resize target | round_up_to_2^N | Realloc? |
|-------|-------------|-------------|-----------------|----------|
| 5 | 1.95GB | 2.44GB | 0x100000000 (4GB) | Yes |
| 6-8 | 1.95~3.91GB | 2.44~3.91GB | 0x100000000 (4GB) | No (capacity
sufficient) |
| **9** | **3.91GB** | **4.10GB** | **0x200000000 (8GB)** | **Yes →
CRASH** |
This issue does **not** occur on x86_64 where LSAN's limit is 1TB.
**Fix:** Skip these two test cases under `LEAK_SANITIZER` build using
`GTEST_SKIP()`. These tests verify the `convert_column_if_overflow` path
(offset overflow from uint32 to uint64), which is not related to leak
detection. They continue to run normally under DEBUG/ASAN/RELEASE builds.
### Release note
None
### Check List (For Author)
- Test
- [ ] Regression test
- [x] Unit Test
- [ ] Manual test (add detailed scripts or steps below)
- [ ] No need to test or manual test. Explain why:
- [ ] This is a refactor/code format and no logic has been changed.
- [ ] Previous test can cover this change.
- [ ] No code files have been changed.
- [x] Other reason: The fix is a test-level GTEST_SKIP guard; the
skipped tests continue to run under non-LSAN builds.
- Behavior changed:
- [x] No.
- [ ] Yes. <!-- Explain the behavior change -->
- Does this need documentation?
- [x] No.
- [ ] Yes. <!-- Add document PR link here. eg:
https://github.com/apache/doris-website/pull/1214 -->
### Check List (For Reviewer who merge this PR)
- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
