环境信息
- Doris 版本：
doris-4.0.5-rc01-59de8c4c524 - JDK：OpenJDK 17.0.18+8
- BE 节点：
10.66.7.1，BackendId1780885838226 - 配置：32 核，约 125GB 内存，TabletNum 17860，磁盘使用率约 35%
- Workload：mix
问题现象
生产环境 BE 在 4.0.5-rc01 上反复 SIGSEGV 崩溃，不是 Linux OOM（dmesg 无 kill 记录）。
最近一次影响业务的故障时间线（2026-06-25）：
| 时间 | 事件 |
|---|---|
| 08:11:34 | BE 启动（PID 419300） |
| ~13:40:22 | BE SIGSEGV 崩溃 |
| 13:41:10 | ETL 任务失败，客户端报错：backend 1780885838226 is down |
| 13:41:55 | BE 自动/脚本重启 |
任务是一个较重的 INSERT INTO ... SELECT ETL（含 TRUNCATE、大表 GROUP BY、UNION ALL、多表 JOIN），跑了约 3 分钟后 BE 挂掉。
崩溃特征（be.out）
观察到 两类 SIGSEGV：
1. 查询执行路径（最常见，6/22~6/25 多次出现）
*** SIGSEGV address not mapped to object (@0x38) *** 4# bthread::TaskGroup::sched_to(...) 5# bthread::TaskGroup::run_main_task() 6# bthread::TaskControl::worker_thread(void*)
2. Page Cache 后台线程（6/25 凌晨）
*** SIGSEGV address not mapped to object (@0x8) *** 10# doris::LRUCache::set_capacity(unsigned long) 14# doris::CacheManager::for_each_cache_refresh_capacity(...) 15# doris::Daemon::cache_adjust_capacity_thread() 6# doris::segment_v2::SegmentFooterPB::~SegmentFooterPB()
近期同一 BE 崩溃记录
| 日期 | Query id | 栈特征 |
|---|---|---|
| 6/22 | 6c0e5ba4c3ab45f2-... | bthread @0x38 |
| 6/23 | 0-0 | bthread @0x38 |
| 6/24 | 7133b64a2c24c1d-... | bthread @0x38 |
| 6/24 | 594b7141026d19bf-... | bthread @0x38 |
| 6/25 00:20 | 0-0 | Page Cache @0x8 |
| 6/25 ~13:40 | 0-0 | bthread @0x38 |
| 同一版本、同一 BE，3 天内至少 6 次 SIGSEGV，怀疑是 4.0.5-rc01 稳定性问题，不只是单条 SQL 太重。 |
已排除的原因
- ❌ Linux OOM Kill（
dmesg无记录） - ❌ 磁盘满（UsedPct ~35%）
- ❌ 人为 shutdown
- ❌ 网络抖动（BE 进程确实 crash 并重启）
触发场景（尚未最小化复现）
- BE 在混合负载下运行数小时
- 执行较重
INSERT INTO ... SELECT（大表扫描 + 20+ 维度 GROUP BY + UNION ALL + 多 LEFT JOIN） - 约几分钟后 BE SIGSEGV，FE 报
backend is down
SQL 模式大致为：
TRUNCATE TABLE dws.xxx- 两段大
INSERT INTO dws.xxx SELECT ...（is_combination=0/1）
完整 SQL 和be.out日志可以私信提供。
期望行为
重查询应查询级失败（内存超限、取消等），不应把整个 BE 进程打崩。
想请教社区
- 4.0.5-rc01 是否有已知的
bthread::TaskGroup::sched_toSIGSEGV 或 Page CacheSegmentFooterPB析构 crash？ - 是否有修复版本建议？RC 是否不建议上生产？
- 除升级外，有无临时规避手段（cache/内存参数、SQL 拆分等）？
附件
可补充：
be.out完整 crash 段be.WARNING13:40~13:42 片段SHOW BACKENDS输出
感谢各位大佬指点 🙏
