@SharkaLaga 大佬，新版本有没有修复呢，这个问题基本上是必现的，现在有用户SQL触发了，所有CN都会重启
这个看起来是3.5.11已修复问题，但是现在3.5.12还是一样的报错，不太确定是不是这个问题，现在复现的环境是什么版本？3.5.15已经推出了，可以试一下
请帮忙看下我这个是不是bug引起的
core dump文件详见：core_segment_flush_25255.xz
链接: https://pan.baidu.com/s/13aMu_VsqRz929abnDCUPhQ 提取码: d8t5
我自己这边分析了一下：
StarRocks BE 节点在执行 segment flush（数据落盘）操作时发生了
SIGSEGV(段错误) 导致进程崩溃。
根据 Core Dump 的 gdb 堆栈分析，崩溃发生在starrocks::RowsetWriter::build(be/src/storage/rowset/rowset_writer.cpp:149)。程序试图在一个空的RowsetMetaPB对象上调用set_num_rows方法（this=0x0）。gdb 打印的局部变量明确显示，传递给该方法的rowset_meta智能指针内部为空 (_M_pi = 0x0)。
gdb 堆栈信息
Core was generated by `/data/starrocks/be/lib/starrocks_be’.
Program terminated with signal SIGSEGV, Segmentation fault.
(gdb) bt full
#0 starrocks::RowsetMetaPB::_internal_set_num_rows (this=0x0, value=0) at be/src/gen_cpp/build/gen_cpp/olap_file.pb.h:7143
No locals.
#1 starrocks::RowsetMetaPB::set_num_rows (this=0x0, value=0) at be/src/gen_cpp/build/gen_cpp/olap_file.pb.h:7146
No locals.
#2 starrocks::RowsetWriter::build (this=0x14800e65ba00) at be/src/storage/rowset/rowset_writer.cpp:149
ts_pb =
rowset_meta = {<std::__shared_ptr<starrocks::RowsetMeta, (__gnu_cxx::_Lock_policy)2>> = {<std::__shared_ptr_access<starrocks::RowsetMeta, (__gnu_cxx::_Lock_policy)2, false, false>> = {},
_M_ptr = 0x10153aa8 <vtable for opentelemetry::v1::nostd::shared_ptropentelemetry::v1::context::Context::DataList::shared_ptr_wrapper+16>,
_M_refcount = {_M_pi = 0x0}}, }
rowset = {<std::__shared_ptr<starrocks::Rowset, (__gnu_cxx::_Lock_policy)2>> = {<std::__shared_ptr_access<starrocks::Rowset, (__gnu_cxx::_Lock_policy)2, false, false>> = {}, _M_ptr =
0x10153aa8 <vtable for opentelemetry::v1::nostd::shared_ptropentelemetry::v1::context::Context::DataList::shared_ptr_wrapper+16>, _M_refcount = {
_M_pi = 0x0}}, }
#3 0x00000000084c8ea4 in starrocks::HorizontalRowsetWriter::build (this=0x14817afeb560) at be/src/storage/rowset/rowset_writer.cpp:814
No locals.
#4 0x0000000007b489f6 in starrocks::DeltaWriter::commit (this=0x14817afeb560) at be/src/storage/delta_writer.cpp:741
res = {<starrocks::internal_statusor::StatusOrData<std::shared_ptrstarrocks::Rowset >> = {{status_ = {state = 0x0}}, {
dummy = {},
data_ = {<std::__shared_ptr<starrocks::Rowset, (__gnu_cxx::_Lock_policy)2>> = {<std::__shared_ptr_access<starrocks::Rowset, (__gnu_cxx::_Lock_policy)2, false, false>> = {}, M_ptr = 0x13, M_refcount = {
M_pi = 0x13}}, }}}, <starrocks::internal_statusor::CopyCtorBase<std::shared_ptrstarrocks::Rowset, true>> = {}, <starrocks::internal_statusor::MoveCtorBase<std::shared_ptrstarrocks::Rowset, true>> = {}, <starrocks::internal_statusor::CopyAssignBase<std::shared_ptrstarrocks::Rowset, true>> = {}, <starrocks::internal_statusor::MoveAssignBase<std::shared_ptrstarrocks::Rowset, true>> = {}, }
span = {static kMaxSize = 32, static kAlignment = 8, buffer = {
data = "(:\025\020\000\000\000\000\000\322H\214\201\024\000\000 RO\214\201\024\000\000c\243,\352ps "}}
scoped = {token = {ptr = 0x147d0d08fc60}}
tracker_setter_L712 = {_old_mem_tracker = 0x148191951a10, _is_same = false}
check_setter_L712 = {_prev_check = true}
state =
watch = {_start = {tv_sec = 9134128, tv_nsec = 57068107}, _total_time = 0, _running = true}
flush_ts = 752
#5 0x0000000007767cc3 in starrocks::SegmentFlushTask::run() ()
#6 0x00000000045d2a07 in starrocks::ThreadPool::dispatch_thread() ()
#7 0x00000000045c8ef0 in starrocks:
:supervise_thread(void*) ()
确认一下BE的版本号, 是3.5.12社区版本, 不是自己编译的吧?
确定是社区版本3.5.12，没有自己编译
再补充一下集群升级信息：原版本是3.1.15，因发现bug，建议打补丁或升级至3.3.20，然后我这边实际执行的是升级至当时的稳定版3.5.12，升级顺序：3.1.15 → 3.1.17 → 3.2.16 → 3.3.22 → 3.4.10 → 3.5.12
上面coredump对应的BE日志, 可以压缩一下也发出来. 这个是导入时写数据挂了, 可能需要结合日志时间线来研究出问题的原因.
这个coredump文件有点时间了，be日志已经不在了。我重新抓一次最新的，到时候把be日志一起出发来。
be日志大概需要拉取宕机前多久的？是所有be节点都要吗？
只需要Core对应BE的日志
收到~
按你们这个重现频繁, 有机会上挑几个节点上 ASAN 版本跑吗? 两个 core 看了, crash 地方都是受害者, 内存被别人写坏了.
具体怎么操作呢？我们目前是3个be节点，上ASAN版本有哪些限制吗？
http://starrocks-cloud-data-zhangjiakou.oss-cn-zhangjiakou.aliyuncs.com/caixiaohua%2Fbranch-3.5%2FASAN%2Fstarrocks-a2e4b58.tar.gz?Expires=1778957888&OSSAccessKeyId=LTAI5tAH5yb1oP5hLQ1oJqqJ&Signature=XRzvm1M1ZSkVnK%2FMA2V6hc48J7w%3D
- 下载这个压缩包, 里面有一个starrocks-a2e4b58/be/lib/starrocks_be文件
- 将原先 BE 部署的 be/lib/starrocks_be 备份
- 创建一个
be/conf/asan_suppressions.conf空文件 - 停 BE 服务
- 用starrocks-a2e4b58/be/lib/starrocks_be这个文件覆盖原先的be/lib/starrocks_be文件
- 启动 BE服务
影响:
- 性能会有损失, 10-20% 不等
先替换一个节点, 你们节点内存比较大, 如果影响太大, 就直接回退.
我们每天上午9点20前后有核心的SQL任务，上了这个版本会不会导致SQL任务跑不起来啊？
还有这个版本部署上去需要跑多久？需要拿哪些信息呢？
跑到出现 crash 时为止. 看你们 crash 容易出现在什么时候, 可以选个低峰时间试一下, 如果影响太大那就回滚.
那还需要配置抓core dump日志吗？
其它都一样, 有 coredump 就收集一下, 日志也收集一下.
可以稍微等一下, 先不要操作, 昨天的 core 有一些新发现.
问题基本定位了, 不用替换 ASAN build 了.