### Describe the bug OBProxy 4.3.4.0 在特定条件下发生 segfault 进程崩溃,已复现多次,均在凌晨 3 点左右批处理任务集中涌入时触发。 ### Environment 项目 | 版本/配置 -- | -- OBProxy 版本 | 4.3.4.0 (obproxy-ce-4.3.4.0-fba87ccf12faba9ba599cd7b0ca4a8149d1abb0e) OceanBase 版本 | 4.3.5.2 (observer) OS | Alibaba Cloud Linux 3 (kernel 5.10.134) 架构 | x86_64 部署方式 | 物理机/云主机,非容器化 内存 | 14G ~ 61G 不等 ### Fast reproduce steps ODP 进程内部发生 segfault,abort() 后 core dump。/var/log/messages 记录的 crash stack trace: `Process <pid> (obproxy) dumped core. Stack trace of thread <pid>: #0 raise (libc.so.6) #1 abort (libc.so.6) #2 n/a (/home/admin/obproxy/bin/obproxy) #3 n/a (/home/admin/obproxy/bin/obproxy) #4 __restore_rt (libc.so.6) #5 __strncasecmp_l_evex (libc.so.6) ← crash point #6 ... obproxy internal ... #7~#38 obproxy event loop / main` crash point: __strncasecmp_l_evex — glibc 的字符串大小写不敏感比较函数,使用 AVX-512 指令优化 直接原因: 传入了非法内存地址(悬垂指针或已释放的内存),导致 segfault signal 处理: ODP 内部捕获 SEGV 信号后调用 abort() ### Expected behavior - ODP 在生产负载下稳定运行,不影响客户端连接 - 字符串比较不访问非法内存 - 进程可稳定运行数周无需重启 ### Actual behavior - ODP 在凌晨 3 点半左右 segfault → abort → core dump - obproxyd.sh 在 1~2 分钟内自动拉起 - 附带 crash stack trace 和首次 segfault 的 dmesg 详情 ### Additional context _No response_
Activity
askdb commentedon Aug 4, 2026
@hophiya Confirmed with the customer: after upgrading to obproxy 4.3.6, no core dumps were observed for more than 5 days.