【 使用环境 】测试环境
【 OB or 其他组件 】OB
【 使用版本 】V2.0.6
【问题描述】使用ODBC驱动执行存储过程相关操作，程序出现Signal：11
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！
根据您描述的情况，OceanBase在通过ODBC驱动执行存储过程时遇到了SegmentFault错误（信号11），这通常指向了某种内存访问异常。为了解决这个问题，我们首先需要收集相关的信息来进一步诊断问题的根本原因。
推荐使用 obdiag 工具进行日志采集，并且将采集到的日志提供给我们以便确认问题所在。
日志采集场景: SQL 执行出错
日志采集命令:
obdiag gather scene run --scene=observer.sql_err --env "{db_connect='-h<your_host> -P<your_port> -u<your_user>@<your_tenant> -p<your_password> -D<your_database>', trace_id='<your_trace_id>'}"
请替换 <your_host>, <your_port>, <your_user>, <your_tenant>, <your_password>, <your_database>, 和 <your_trace_id> 为您实际的数据库连接信息和发生错误时的trace id。如果不确定trace id是什么，您可以尝试留空或提供一个近似的日期时间范围作为estimated_time字段的一部分，在px_collect_log场景中指定，但这主要用于跟踪SQL PX的问题。对于SQL执行错误，主要依赖于准确的trace id来定位具体的错误记录。
执行上述命令后，会生成一个包含必要诊断信息的日志压缩包。请您将这个文件发送给我们以供分析。
另外，为了确定具体的问题，在此需要您提供一些信息：
- 发生故障的具体时间点（尽可能精确）以及是否有重复出现该现象的时间段。
- 执行存储过程前后的所有相关操作步骤或脚本，包括创建表、插入数据等准备工作及之后的操作。
- 您能否分享遇到问题的存储过程代码？或者至少告诉我们它试图完成什么样的逻辑？
- 在出现问题之前，您的应用是否经历了显著的工作负载变化或进行了其他可能影响系统稳定性的更改？
- 您是否有观察到任何不寻常的日志输出或其他警告/错误消息，特别是在OceanBase服务端？
- ODBC驱动程序版本是多少？是否有考虑过尝试更新至最新版本来看是否可以解决该问题？
以上信息将有助于我们更深入地理解问题背景，从而加快诊断过程。期待您的回复！
附上敏捷诊断工具 obdiag 使用帮助链接
ob是哪个版本 mysql模式么？
ob版本是4.2.5，mysql模式