@Rocky BE pods getting crashed

*** Aborted at 1781161391 (unix time) try "date -d @1781161391" if you are using GNU date ***
PC: @          0x8dee058 starrocks::BinaryColumnBase<unsigned int>::append(starrocks::Column const&, unsigned long, unsigned long)
*** SIGSEGV (@0x616c702d73676e) received by PID 27 (TID 0xfffdece4fa00) LWP(612) from PID 762537838; stack trace: ***
    @     0xffffae2553dc (/usr/lib/aarch64-linux-gnu/libc.so.6+0x853db)
    @         0x10c11978 google::(anonymous namespace)::FailureSignalHandler(int, siginfo_t*, void*)
    @     0xffffaf906838 ([vdso]+0x837)
    @          0x8dee058 starrocks::BinaryColumnBase<unsigned int>::append(starrocks::Column const&, unsigned long, unsigned long)
    @          0x8e7a1ec starrocks::Chunk::append(starrocks::Chunk const&, unsigned long, unsigned long)
    @          0xcf4c0e0 starrocks::ChunkPipelineAccumulator::push(std::shared_ptr<starrocks::Chunk> const&)
    @          0xc12b35c starrocks::pipeline::ChunkAccumulateOperator::push_chunk(starrocks::RuntimeState*, std::shared_ptr<starrocks::Chunk> const&)
    @          0xc0b0270 starrocks::query_cache::MultilaneOperator::push_chunk(starrocks::RuntimeState*, std::shared_ptr<starrocks::Chunk> const&)
    @          0xad2a55c starrocks::pipeline::PipelineDriver::process(starrocks::RuntimeState*, int)
    @          0xbd80a7c starrocks::pipeline::GlobalDriverExecutor::_worker_thread()
    @          0xd8b8a94 starrocks::ThreadPool::dispatch_thread()
    @          0xd8af608 starrocks::Thread::supervise_thread(void*)
    @     0xffffae250398 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x80397)
    @     0xffffae2b9e9c (/usr/lib/aarch64-linux-gnu/libc.so.6+0xe9e9b)
[1781161391.865][thread: 281466066237952] je_mallctl execute purge success
[1781161391.865][thread: 281466066237952] je_mallctl execute dontdump success
start time: Thu Jun 11 07:05:45 UTC 2026, server uptime:  07:05:45 up  1:23,  0 users,  load average: 4.78, 7.29, 6.70
Run with JEMALLOC_CONF: 'percpu_arena:percpu,oversize_threshold:0,muzzy_decay_ms:5000,dirty_decay_ms:5000,metadata_thp:auto,background_thread:true,prof:true,prof_active:false'
Ignored unknown config: default_rowset_type
4.0.10 RELEASE (build 5b36164 distro ubuntu arch aarch64)

The crash in your StarRocks BE pods (v4.0.10) appears to be a known issue related to the Query Cache mechanism, specifically within the

MultilaneOperator

. Analysis The stack trace shows the segmentation fault occurs in

starrocks::query_cache::MultilaneOperator::push_chunk

when trying to append data to a binary column. This is a characteristic symptom of a bug in how the Query Cache handles data chunks in the pipeline engine. Similar crashes have been reported in the community (e.g., Issue #61361), where partitioned hash joins or complex queries with Query Cache enabled trigger a

SIGSEGV

. Recommended Workarounds To stabilize your cluster immediately, you should disable the Query Cache: 1. Disable at the Session or Global level:

sql
    -- Disable for the current session
    SET enable_query_cache = false;

    -- Or disable globally for all new sessions
    SET GLOBAL enable_query_cache = false;

2. Verify Pipeline Engine: The Query Cache only operates when the Pipeline Engine is active. While it's generally recommended to keep the pipeline engine enabled, disabling it would also stop this specific crash path (though this is not recommended as a first step):

sql
    SET GLOBAL enable_pipeline_engine = true; -- Keep this true, just disable query_cache

Long-term Fix * Upgrade: A fix for this specific

MultilaneOperator

crash is slated for version 4.1.0. If you cannot wait for the 4.1 release, check the latest 4.0.x patches (beyond 4.0.10) as fixes are often backported. * ARM-Specific Stability: Since you are running on

aarch64

, ensure your environment doesn't have memory ordering issues, as some recent reports (Issue #66347) suggest ARM-specific segfaults in

BinaryColumnBase

under high concurrency. However, the presence of

query_cache

in your stack trace makes the Query Cache the primary suspect. If disabling the Query Cache does not resolve the issue, please provide the specific query ID or SQL pattern that triggers the crash for further investigation.