@Rocky i came accross a crash # BE SIGSEGV in MapColumn::append (ChunkAccumulateOperator) on UNNEST(map_keys(map_col)) over a large scan ## Environment - StarRocks 4.1.1 (build 14b7e3f), ubuntu, ***aarch64***, shared-nothing, 6 BEs (8 CPU / 96 GiB each), Kubernetes (operator) - Primary Key table

db.events

, day-partitioned on a DATETIME,

DISTRIBUTED BY HASH(k3) BUCKETS 1

, two nullable MAP columns:

attrs_text MAP<VARCHAR(128), VARCHAR(65533)> DEFAULT NULL

,

attrs_num MAP<VARCHAR(128), DOUBLE> DEFAULT NULL

- ~20M rows, ~1.4M rows/day; many rows have NULL maps, others 5-40 keys -

db.event_links

and

db.dim_category

are small Primary Key tables (tens of thousands of rows) ## Steps to reproduce Query (a map-key survey; the same statement completes fine when the time filter covers 2-3 days, ~3M rows):

sql
WITH t AS (
    SELECT d.category, f.attrs_text, f.attrs_num
    FROM db.events f
    JOIN db.event_links l ON l.k1 = f.k1 AND l.k2 = f.k2 AND l.k3 = f.k3
    JOIN db.dim_category d ON d.id = l.category_id
    WHERE f.event_ts >= DATE_SUB(NOW(), INTERVAL 14 DAY)
),
k AS (
    SELECT category, k AS key_name FROM t, UNNEST(map_keys(attrs_num)) AS u(k)
    UNION ALL
    SELECT category, k FROM t, UNNEST(map_keys(attrs_text)) AS u(k)
)
SELECT category, key_name, COUNT(*) AS n
FROM k
WHERE key_name LIKE '%foo%' OR key_name LIKE '%bar%'
GROUP BY 1, 2 ORDER BY 1, 3 DESC;

With the 14-day filter (~20M input rows), 5 of the 6 BEs crashed within the same second (exit code 139). The FE returned:

Backend node not found. Check if any backend node is down. backend: [... alive: true inBlacklist: true] x6

## Crash stack (identical on every crashed BE)

plan_node_id:24
*** Aborted at 1787740173 (unix time) ***
PC: @ 0xa81ee84 starrocks::BinaryColumnBase<unsigned int>::append(starrocks::Column const&, unsigned long, unsigned long)
*** SIGSEGV (@0x0) received by PID 27 ***
    @ 0xa81ee84 starrocks::BinaryColumnBase<unsigned int>::append(starrocks::Column const&, unsigned long, unsigned long)
    @ 0xa85a8e8 starrocks::MapColumn::append(starrocks::Column const&, unsigned long, unsigned long)
    @ 0xa82c474 starrocks::NullableColumn::append(starrocks::Column const&, unsigned long, unsigned long)
    @ 0xa82e73c starrocks::Chunk::append(starrocks::Chunk const&, unsigned long, unsigned long)
    @ 0xf6a93ac starrocks::ChunkPipelineAccumulator::push(std::shared_ptr<starrocks::Chunk> const&)
    @ 0xe72ea1c starrocks::pipeline::ChunkAccumulateOperator::push_chunk(starrocks::RuntimeState*, std::shared_ptr<starrocks::Chunk> const&)
    @ 0xcea6bbc starrocks::pipeline::PipelineDriver::process(starrocks::RuntimeState*, int)
    @ 0xe37f2dc starrocks::pipeline::GlobalDriverExecutor::_worker_thread()
    @ 0x1014e384 starrocks::ThreadPool::dispatch_thread()
    @ 0x101450cc starrocks::thread::supervise_thread(void*)

## Expected The query completes (or fails with a memory error); a BE should not segfault.

SIGSEGV (@0x0)

inside

BinaryColumnBase::append

reached through

MapColumn::append

suggests a null / uninitialised key column in a MAP chunk being accumulated - possibly a chunk whose MAP column is entirely NULL or a MAP with zero keys.

This crash is a known issue in the StarRocks 4.1.x branch (similar to reports in #77477 and #65073), specifically relating to how the pipeline engine handles complex types like

MAP

during chunk accumulation. Analysis of the Crash The stack trace indicates that the crash occurs within the

ChunkAccumulateOperator

. This operator is responsible for gathering multiple small chunks into a single larger chunk (typically to optimize network transmission or join performance). 1. Null Pointer Dereference: The

SIGSEGV (@0x0)

inside

BinaryColumnBase<unsigned int>::append

suggests that the internal data structures of the

MapColumn

(specifically the

offsets

or the underlying

bytes

of the

VARCHAR

keys/values) are either uninitialized or have been cleared/reset improperly in the chunk being appended to. 2. Trigger Mechanism: As you observed, this only happens on "large scans" (~20M rows). In larger datasets, the

ChunkAccumulateOperator

is more likely to encounter chunks where the

MAP

columns are entirely

NULL

or contain empty maps. Under certain conditions in the 4.1.x pipeline, the template chunk used for accumulation may fail to properly initialize the nested

keys

and

values

columns of the

MapColumn

when the source data is predominantly NULL. 3. Architecture (aarch64): While the logic error is cross-platform, the

aarch64

environment sometimes exposes these uninitialized memory issues more frequently due to different memory ordering or compiler optimizations in the SIMD-accelerated column operations. Recommended Workarounds Until a fix is applied in a later patch (check for 4.1.2 or 4.1.3+ releases), you can try the following to mitigate the crash: * Filter NULLs Early: Modify your CTE

t

to explicitly filter out rows where both map columns are NULL. This can prevent "all-NULL" chunks from reaching the accumulator:

sql
    WITH t AS (
        SELECT d.category, f.attrs_text, f.attrs_num
        FROM db.events f
        JOIN ...
        WHERE f.event_ts >= DATE_SUB(NOW(), INTERVAL 14 DAY)
          AND (f.attrs_text IS NOT NULL OR f.attrs_num IS NOT NULL) -- Add this
    ),

* Adjust Batch Size: Sometimes reducing the

pipeline_max_buffered_chunks

or increasing the

chunk_size

can bypass the specific accumulation logic that triggers the bug, though this is a trial-and-error approach.

sql
    SET [GLOBAL] chunk_size = 2048; -- Default is 4096; smaller chunks might avoid some accumulation scenarios

* Materialization Avoidance: The crash is likely happening because the optimizer is materializing the CTE

t

because it is referenced twice (in the

UNION ALL

). You can try to rewrite the query to avoid the

UNION ALL

over the same CTE, or use a temporary table if the logic allows, to isolate the join from the unnesting. Next Steps 1. Check for Patches: Verify if there is a version later than

4.1.1 (build 14b7e3f)

. Recent release notes (around July/August 2026) mention fixes for

ARRAY

and

MAP

capacity limits and memory layout (#76419) which may address this. 2. Community Support: Since this involves a BE segmentation fault in a very recent version, I recommend providing this stack trace to the StarRocks community on Slack or opening a GitHub issue if #77477 does not already cover your specific case. You should include the output of

EXPLAIN VERBOSE <query>

to help maintainers see exactly where

plan_node_id:24

sits in the pipeline. References • sql-reference/data-types/semi_structured/Map.md • sql-reference/sql-functions/map-functions/map_from_arrays.md