Hi @Rocky We're upgrading a shared-data StarRocks cluster from 4.0.8 to 4.1.0 on k8s (EKS, operator v1.11.4) and the CN is crashing with a segfault before producing any output. The FE came up clean on 4.1.0. Only the CN is affected. Crash (4.1.0 CN)

[Wed Apr 15 15:09:47 UTC 2026] run start_cn.sh
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'
/opt/starrocks/cn_entrypoint.sh: line 165: 27 Segmentation fault (core dumped) $STARROCKS_HOME/bin/start_cn.sh

The 4.1.0 CN binary produces zero output, no version line, no "CN start step 1". It segfaults before any user-space CN code executes. For reference, here is what a rolled back 4.0.8 CN startup looks like on the same node immediately after JEMALLOC_CONF:

version 4.0.8-2090bfc
BuildType: RELEASE, Build arch: x86_64
Built on 2026-03-24 by StarRocks@localhost (Ubuntu 22.04.5 LTS)
CPU: Intel Xeon Platinum 8488C, 4 cores, AVX/AVX2/AVX512f/AVX512bw
Physical Memory: 16.00 GB
CN start step 1: daemon threads start successfully
...
CN started successfully

Key facts: Same node (

ip-10-110-240-182.ec2.internal

), same cn.conf, freshly provisioned PVCs FE on 4.1.0 is healthy • Rolling back to

cn-ubuntu:4.0.8

recovers immediately cn.conf:

mem_limit = 85%
datacache_enable = true
datacache_mem_size = 20%
datacache_disk_size = 80%
primary_key_limit_size = 512
max_cumulative_compaction_num_singleton_deltas = 100
lake_enable_vertical_compaction_fill_data_cache = true
memory_urgent_level = 80
memory_high_level = 70

Is this a known issue with

cn-ubuntu:4.1.0

? Could it be a static initializer crash or a library incompatibility? Any config parameters above that were removed or renamed in 4.1 that could cause an early crash?

Hi there! I'm Rocky. Based on the details you've shared, this looks like a specific issue with the StarRocks 4.1.0 CN (Compute Node) startup in a shared-data environment, likely related to the major internal changes introduced in the 4.1.x branch. Since your CN is producing zero output (not even the version line) and segfaulting immediately, the crash is occurring in a static initializer or during the loading of shared libraries, before the main program logic even starts. 1. Potential Image/Library Incompatibility In StarRocks 4.1.0, there were updates to the build toolchain and base images. * GLIBC version: Your 4.0.8 log shows it was built on Ubuntu 22.04.5. If the

cn-ubuntu:4.1.0

image was built on a newer base (like Ubuntu 24.04), it may have a higher GLIBC requirement. * Recommendation: Try using the

cn-redhat:4.1.0

image instead of

cn-ubuntu

. The RedHat/CentOS-based images are often more stable regarding library linking in diverse K8s environments. 2. Jemalloc Profiling Conflict Your

JEMALLOC_CONF

includes

prof:true,prof_active:false

. * In some 4.1.0 builds, if the binary was not explicitly compiled with jemalloc profiling support, setting

prof:true

in the environment can cause an immediate abort/segfault during the memory allocator's initialization. * Troubleshooting: Temporarily remove

prof:true

or set it to

prof:false

in your environment variables to see if the process starts. 3. Unified Cache & Percentage Parsing StarRocks 4.1.0 introduced Large-Capacity Tablet Support (Phase 1) and a refactored Unified Cache. * The Issue: Your config uses

datacache_mem_size = 20%

and

datacache_disk_size = 80%

. There have been reported cases in early 4.1 versions where the percentage parser for the new cache system fails to initialize correctly if the calculated values are unexpected or if the

%

sign causes a parsing error in a specific internal block. * Troubleshooting: Try replacing the percentages with absolute values (e.g.,

datacache_mem_size = 4G

) to rule out a parser-level crash. 4.

primary_key_limit_size

Change In version 4.1, the Persistent Index (used by Primary Key tables) underwent significant layout changes to support tablets up to 100GB. * The default is

128

. You have it set to

512

. * While this is a valid parameter, the new indexing structures in 4.1 might be sensitive to this setting during their static initialization if they assume different memory alignment or overheads. * Troubleshooting: Comment out

primary_key_limit_size = 512

and let it use the default (128) just to check if it bypasses the early crash. 5. Removed/Deprecated Parameters The parameters

memory_high_level

and

memory_urgent_level

were part of the older memory management system. StarRocks 4.x has moved towards StarMemory (Unified Memory Management). * While unknown parameters usually just log a warning, in a "shared-data" (Lake) context, 4.1.0 might be strictly validating these against the new

lake_

specific memory controllers. Recommended Next Steps: 1. Run with `--version`: If you can shell into the container (even if it's crashing, you can try

kubectl run --image... -- /opt/starrocks/be/bin/starrocks_be --version

), check if the binary itself is executable. If

starrocks_be --version

segfaults, it is 100% a library/OS compatibility issue. 2. Check Pod Logs (not just entrypoint): Ensure there isn't a "kernel too old" or "invalid instruction" hidden before the entrypoint output. 3. Switch Image: Switch to

cn-redhat:4.1.0

to see if the behavior persists. Note on Downgrade: Since you are at 4.0.8, you are safe. Version 4.1.0 only forbids downgrading to versions below 4.0.6 due to tablet metadata changes. References • administration/management/BE_configuration.md • release_notes/release-3.2.md

could be related to this: https://github.com/StarRocks/starrocks/issues/71731