Environment
- Version: observer (OceanBase seekdb)
- Build Info:
Starting seekdb (OceanBase seekdb) source revision 1-bf32facb8aa138eb526b6f8f88ec6951184c8620.
observer (OceanBase seekdb)
REVISION: 1-bf32facb8aa138eb526b6f8f88ec6951184c8620
BUILD_BRANCH: master
BUILD_TIME: Jun 1 2026 23:53:51
BUILD_FLAGS: RelWithDebInfo|Sanity
BUILD_INFO: obbuild-sanity-master-101075
- Is this a temporary version provided by RD?: No
- Reproducibility: To be determined
- Test Changes: To be determined
- Other environmental anomalies or changes: To be determined
- Environment Information:
- Jenkins job link: http://:9090/jenkins/job/ddltest_duomo_lite/278/
Description
This is not a random segmentation fault. The observer process was actively aborted by itself, with the root cause being a memory sanity check (memory_sanity) failure that occurred while a DDL scheduling thread was printing logs.
Key details:
- Core file:
/data/1/core-T1_DDLTaskExecu-1502072-1780399935
- Executable:
/data/1/vec_stress/ddl_duomo/obm.z1.obs0/bin/observer
- Termination signal:
SIGABRT (active abort)
Key call stack (crashing thread T1_DDLTaskExecu):
raise -> abort -> memory_sanity_abort
ObLogPrintPointerCnt<ObTableSchema*>::to_string
ObCreateDDLTaskParam::to_string
ObDDLScheduler::create_ddl_task
ObTableRedefinitionTask::copy_table_indexes / process
This indicates:
- During
create_ddl_task logging (e.g., "create ddl task(ret=0, param=...)"), printing the param triggered a memory sanity check on a schema pointer (likely related to vector/hybrid index fields).
- This appears to be a dangling pointer / lifetime issue (UAF-like) rather than a typical SQL execution failure.
- The
CHECK_CORE_OCCURS seen in the logs corresponds to this abort event.
Additional clues:
- The thread stack contains
DDL_CREATE_VEC_INDEX, ObPluginVectorIndexLoadScheduler, and ObCreateDDLTaskParam, which aligns with the stress test scenario (hybrid/vector index + high-frequency DDL).
- The
GATHER_SCHEMA_STATS warning is not the direct crash point; the actual crash occurs during log printing in the rootservice DDL scheduling path.
Steps to Reproduce
To be determined. The issue occurred during a workload involving hybrid/vector index creation and high-frequency DDL operations.
Log Information
GDB output (core analysis):
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/data/1/vec_stress/ddl_duomo/obm.z1.obs0/bin/observer'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f5103441005 in raise from /usr/lib64/libc.so.6
[Current thread is 1 (Thread 0x7f50f4c3d240 (LWP 1502169))]
exe = '/data/1/vec_stress/ddl_duomo/obm.z1.obs0/bin/observer'
Id Target Id Frame
* 1 Thread 0x7f50f4c3d240 (LWP 1502169) 0x00007f5103441005 in raise from /usr/lib64/libc.so.6
2 Thread 0x7f50f5771240 (LWP 1502092) 0x00007f510342a9cd in syscall from /usr/lib64/libc.so.6
3 Thread 0x7f50f567d240 (LWP 1502090) 0x00007f51035da9d8 in pthread_cond_timedwait@@GLIBC_2.3.2 from /usr/lib64/libpthread.so.0
4 Thread 0x7f50f54b7240 (LWP 1502095) 0x00007f510342a9cd in syscall from /usr/lib64/libc.so.6
5 Thread 0x7f50f54f1240 (LWP 1502096) 0x00007f510342a9cd in syscall from /usr/lib64/libc.so.6
6 Thread 0x7f50f4399240 (LWP 1721271) 0x00007f510342a9cd in syscall from /usr/lib64/libc.so.6
7 Thread 0x7f50f4e77240 (LWP 1502193) 0x00007f51034f5a31 in clock_nanosleep@GLIBC_2.2.5 from /usr/lib64/libc.so.6
8 Thread 0x7f50f57eb240 (LWP 1502093) 0x00007f510342a9cd in syscall from /usr/lib64/libc.so.6
9 Thread 0x7f51033ea6c0 (LWP 1502072) 0x00007f51034f5a31 in clock_nanosleep@GLIBC_2.2.5 from /usr/lib64/libc.so.6
10 Thread 0x7f50f4b99240 (LWP 1899925) 0x00007f510342a9cd in syscall from /usr/lib64/libc.so.6
11 Thread 0x7f50f4cb1240 (LWP 1502171) 0x00007f51035da9d8 in pthread_cond_timedwait@@GLIBC_2.3.2 from /usr/lib64/libpthread.so.0
12 Thread 0x7f50f3b25240 (LWP 1856154) 0x00007f510342a9cd in syscall from /usr/lib64/libc.so.6
13 Thread 0x7f50f4e3d240 (LWP 1502192) 0x00007f51035da9d8 in pthread_cond_timedwait@@GLIBC_2.3.2 from /usr/lib64/libpthread.so.0
14 Thread 0x7f50f463d240 (LWP 1502200) 0x00007f51035da9d8 in pthread_cond_timedwait@@GLIBC_2.3.2 from /usr/lib64/libpthread.so.0
15 Thread 0x7f50f3ab1240 (LWP 1856131) 0x00007f510342a9cd in syscall from /usr/lib64/libc.so.6
16 Thread 0x7f50f4999240 (LWP 1502198) 0x00007f51034f5a31 in clock_nanosleep@GLIBC_2.2.5 from /usr/lib64/libc.so.6
17 Thread 0x7f50f3e77240 (LWP 1502851) 0x00007f510342a9cd in syscall from /usr/lib64/libc.so.6
18 Thread 0x7f50f483d240 (LWP 1877469) 0x00007f510342a9cd in syscall from /usr/lib64/libc.so.6
19 Thread 0x7f50f435f240 (LWP 1721266) 0x00007f510342a9cd in syscall from /usr/lib64/libc.so.6
Relevant log snippet (/data/1/vec_stress/ddl_duomo/obm.z1.obs0/log/seekdb.log):
[2026-06-02 19:32:10.086961] WDIAG [COMMON] check_stack_overflow ... [1899891][T1_ReqWorker] ...
stack possible overflow(... reserved_size=196608 ...)
[2026-06-02 19:32:10.087499] WDIAG [COMMON] check_stack_overflow ... [1502169][T1_DDLTaskExecu] ...
stack possible overflow(... reserved_size=196608 ...)
lbt=... 0x64637b1 0x64a0ada 0x68378c0 0x664228d ...
Environment
Description
This is not a random segmentation fault. The observer process was actively aborted by itself, with the root cause being a memory sanity check (memory_sanity) failure that occurred while a DDL scheduling thread was printing logs.
Key details:
/data/1/core-T1_DDLTaskExecu-1502072-1780399935/data/1/vec_stress/ddl_duomo/obm.z1.obs0/bin/observerSIGABRT(active abort)Key call stack (crashing thread
T1_DDLTaskExecu):raise -> abort -> memory_sanity_abortObLogPrintPointerCnt<ObTableSchema*>::to_stringObCreateDDLTaskParam::to_stringObDDLScheduler::create_ddl_taskObTableRedefinitionTask::copy_table_indexes / processThis indicates:
create_ddl_tasklogging (e.g.,"create ddl task(ret=0, param=...)"), printing theparamtriggered a memory sanity check on a schema pointer (likely related to vector/hybrid index fields).CHECK_CORE_OCCURSseen in the logs corresponds to this abort event.Additional clues:
DDL_CREATE_VEC_INDEX,ObPluginVectorIndexLoadScheduler, andObCreateDDLTaskParam, which aligns with the stress test scenario (hybrid/vector index + high-frequency DDL).GATHER_SCHEMA_STATSwarning is not the direct crash point; the actual crash occurs during log printing in the rootservice DDL scheduling path.Steps to Reproduce
To be determined. The issue occurred during a workload involving hybrid/vector index creation and high-frequency DDL operations.
Log Information
GDB output (core analysis):
Relevant log snippet (
/data/1/vec_stress/ddl_duomo/obm.z1.obs0/log/seekdb.log):