It sounds like you've encountered a memory corruption issue related to Late Materialization in the

SegmentIterator

. The fault address

0x4f656572676544

translates to ASCII bytes (possibly part of a string like

"DegreeO"

or similar data from your tables), which confirms your suspicion of a use-after-free or memory overwrite where string data has clobbered a pointer. Analysis of the Crash The function

SegmentIterator::_switch_context

is a core part of StarRocks' vector query engine. It is responsible for switching between: 1. Evaluation Context: Reading only columns required for predicates to filter rows. 2. Materialization Context: Reading the remaining columns for the rows that passed the filters. In StarRocks 4.0.x, there have been significant changes to how JSON is handled (FlatJSON V2), and there is a known sensitivity in the

SegmentIterator

when complex predicates (like

get_json_string

on a

VARCHAR

or

JSON

column) are combined with late materialization and JOINs. The fact that it only reproduces on multi-BE clusters often points to how data distribution and certain shuffle/join optimizations interact with the local scan path on the BE, potentially triggering specific late materialization thresholds that a single BE doesn't hit. Recommended Workarounds Before filing a GitHub issue (which you should definitely do, given you have a reproducible case), you can try the following workarounds to stabilize your cluster: 1. Disable Late Materialization: This is the most direct way to bypass the code path in

_switch_context

.

sql
    SET late_materialization_ratio = 0;

Note: This might slightly increase I/O for queries that were benefiting from skipping data, but it usually prevents this specific crash. 2. Disable CBO JSON V2 Rewrite: There is a known bug (#63677) where

get_json_string

on certain fields can cause instability. Disabling the V2 rewrite forces a more conservative (and stable) parsing path.

sql
    SET cbo_json_v2_rewrite = false;

3. Disable Parquet Late Materialization (if using external tables): If your dim tables or source data are in Parquet format:

sql
    SET parquet_late_materialization_enable = false;

Next Steps for Reporting Since you are on 4.0.8/4.0.9, this appears to be a regression or a lingering issue in the 4.0 line. When you file the GitHub issue, please include: * The

be.out

log containing the full stack trace. * The

EXPLAIN ANALYZE

output of the query (if it finishes once before crashing). * The fact that the fault address looks like your data (mentioning the ASCII translation). If you're able to share the table schema and the query (even an anonymized version) in the GitHub issue, it will help the maintainers pinpoint exactly which materialization path is failing.