OBServer 执行大量 fetch 和 close 操作后偶现 coredump

问题现象

fetch 操作获取完数据或者 fetch 0 行数据时，server 会主动 close_cursor，此时的 close_cursor 没有被 session 锁 lock, 又因为 close 协议是非阻塞的，如果 server 内部对同一个 session，同一个 stmt_id 同时执行这两个协议，那么就有可能出现并发访问 cursor 内存的情况。

问题原因

fetch 主动 close_cursor 的时候没有加上 session 锁。

问题的风险及影响

偶现 coredump。

影响的版本

OceanBase 数据库 V2.2.77 GA（oceanbase-2.2.77-20210508211731）及之后版本、V3.1.2 GA（oceanbase-3.1.2-20210618150922）及之后版本、V3.2.3 GA（oceanbase-3.2.3.0-20220418212020）及之后版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之后版本。

解决方法及规避方式

• 如果频繁出现此现象时可以减小应用的并发度并保证 fetch 和 close 的执行顺序，确保先 fetch 后 close。

• 升级到已修复版本。目前已修复的版本包括 OceanBase 数据库 V2.2.77 BP15（oceanbase-2.2.77-115000012023010607）及之后版本、V3.1.2 BP11（oceanbase-3.1.2-111000052023010412）及之后版本、V3.2.3 BP6 Hotfix1（oceanbase-3.2.3.3-106000102022111521）版本、V3.2.3 BP6 Hotfix2（）版本、V3.2.3 BP6 Hotfix2（oceanbase-3.2.3.3-106020042022120915）版本、V3.2.3 BP6 Hotfix3（oceanbase-3.2.3.3-106030012022121311）版本、V3.2.3 BP6 Hotfix4（oceanbase-3.2.3.3-106040022022122222）版本、V3.2.3 BP6 Hotfix5（oceanbase-3.2.3.3-106050012023051617）版本、V3.2.3 BP7（oceanbase-3.2.3.3-107000092023011911）及之后版本、V3.2.4 BP1（oceanbase-3.2.4.1-101000052023010822）及之后版本。