【 使用环境 】测试环境
【 OB or 其他组件 】
【 使用版本 】4.3.5.1
【问题描述】observer服务无法启动，重启后很快又继续崩溃，循环往复，已经无法正常运行
【复现路径】服务重启一直出现下面的错误，导致进程崩溃退出，由于无法上传完整日志附件，只能提供关键报错日志。
【附件及日志】
CRASH ERROR!!! IP=555b99b4f141, RBP=2acb5c051e60, sig=11, sig_code=1, sig_addr=0x3, RLIMIT_CORE=unlimited, timestamp=1757573958119986, tid=37250, tname=T1002_PX_G0, trace_id=Y300B427F000001-00063566A3CECA43-0-0, lbt=0x2381fd28 0x237f9ccd 0x2ac8dc22c62f 0x8f5f141 0x15841320 0x8f37b78 0x90d518c 0x8cb8b9d 0x148429f7 0x14842bbf 0x8cba62a 0x927577f 0x8cba62a 0x15332934 0x8cba62a 0x11eea36c 0x8cba62a 0x11ef0c9a 0x11ed2ce3 0x11ecde96 0x11ee8082 0x1490e276 0x14953bbb 0x110af291 0x110aee01 0x22e6ba7d 0x2ac8dc224ea4 0x2ac8dc53796c, SQL_ID=6E0D0810696543A12F06646578C79447, SQL_STRING=INSERT /*+ monitor enable_parallel_dml parallel(1) opt_param(‘ddl_execution_id’, 3) opt_param(‘ddl_task_id’, 76041387) opt_param
[2025-09-11 14:59:18.120139] INFO [STORAGE] inc_ref_with_macro_iter (ob_tablet.cpp:3116) [37033][T1002_TimerWK4_SSTableDefragme][T1002][Y0-0000000000000000-0-0] [lt=232] the tablet that inner increases ref cnt is(ret=0, hold_ref_cnt_=false, ls_id={id:1001}, tablet_id={id:1152921504607258821}, table_store_addr_.addr_={[ver=1,mode=0,seq=67175605][2nd=66737][3rd=0][offset=290816,size=354,type=2,seq=0][trans_seq=0, sec_part=0][6th=0]}, storage_schema_addr_.addr_={[ver=1,mode=0,seq=67175605][2nd=66737][3rd=0][offset=291170,size=209,type=2,seq=0][trans_seq=0, sec_part=0][6th=0]}, tablet_addr_={[ver=1,mode=0,seq=67175602][2nd=12593][3rd=0][offset=1835008,size=713,type=4,seq=0][trans_seq=0, sec_part=0][6th=0]}, this=0x2acb3a4ac060, macro_iter={macro_info:{entry_block:{[ver=1,mode=0,seq=0][2nd=18446744073709551615]}, meta_block_info_arr:{cnt:0, arr:null, capacity:0}, data_block_info_arr:{cnt:0, arr:null, capacity:0}, shared_meta_block_info_arr:{cnt:1, arr:0x2acb3a4ac7a0, capacity:1}, shared_data_block_info_arr:{cnt:1, arr:0x2acb3a4ac7d0, capacity:1}, is_inited:true}, cur_type:4, target_type:6, is_linked:false}, lbt()=“0x95997d6 0x19ad3432 0x96e2f16 0x19a94c51 0x19abd55a 0x9212eac 0x9279975 0x1a31e876 0x9067e0e 0x901c647 0x22e6de95 0x22e6ba7e 0x2ac8dc224ea5 0x2ac8dc53796d”)
是不是硬件出现了问题，日志没有看出来？看看是不是磁盘故障
提供的日志里也看不出个什么来，
确实是，这个日志也看不出太多有用的信息来。我觉从硬件资源使用情况，先着手看看，看资源怎么样，内存够不够，再有就是时间同步有没有问题。分布式对时间一致性要求比较高。
CRASH ERROR。看一下是否有core文件生成。
新部署的集群么？
1.单节点observer已经使用了几个月了，存储了上千万条数据。
2.服务器是物理服务器，目前稳定运行，没有任何硬件异常，及操作系统内核相关的错误日志，包括存储及io都未见任何异常。
3.服务器资源充足：
128G内存64核CPU 2TBSSD，运行稳定
[root@node-1673101502 ~]# top
top - 10:23:56 up 137 days, 1:44, 1 user, load average: 0.08, 0.08, 0.12
Tasks: 787 total, 2 running, 784 sleeping, 0 stopped, 1 zombie
%Cpu(s): 0.1 us, 0.1 sy, 0.0 ni, 99.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 13167492+total, 12671656 free, 32450692 used, 86552576 buff/cache
KiB Swap: 33554428 total, 29252512 free, 4301916 used. 98159136 avail Mem
[root@node-1673101502 ~]# free -m
total used free shared buff/cache available
Mem: 128588 31690 12375 268 84522 95858
Swap: 32767 4201 28566
4.崩溃后有一堆core文件，
[root@node-1673101502 ~]# du -sh /data/oceanbase/data/observer/core.*
14G /data/oceanbase/data/observer/core.14341
13G /data/oceanbase/data/observer/core.35635
13G /data/oceanbase/data/observer/core.44634
50G /data/oceanbase/data/observer/core.725
…
压缩一下core文件看看能压多大，是否能压到4G以下。这边麻烦留一下你的钉钉号
你好 我的钉钉号 m0921ue 我已经压缩了一个最小的1.6G
有进展麻烦这边回复下，我们也是用的这个版本。看看是什么bug
他这个是个向量问题。多值索引后建数组大小超过32个元素导致
根因分析及解决办法：
打开配置项_enable_add_fulltext_index_to_existing_table后，在有超过32个元素的json列上创建多值索引。
json列中超过32个元素时，访问越界导致core。
影响版本/修复版本：
4340和4353中间的所有版本都存在这个问题，4354开始修复。