SIG-11 when executing lots of CREATE TABLE queries
This is an issue that was observed while trying to execute the CREATE TABLE commands for a VistA environment where there are around 7042 tables each of which has a lot of columns with fancy DDL specifications.
$ src/octo -f vista_ddal.sql
%YDB-F-KILLBYSIGSINFO1, YottaDB process 6033 has been killed by a signal 11 at address 0x00007F0CB4FECE10 (vaddr 0x0000000005464FD8)
%YDB-F-SIGMAPERR, Signal was caused by an address not mapped to an object
And below is the C-stack corresponding to the core file.
Core was generated by `octo -f vista2.sql'.
Program terminated with signal 3, Quit.
#0 0x00007f0cb4117aa1 in pthread_kill () from /lib64/libpthread.so.0
#0 0x00007f0cb4117aa1 in pthread_kill () from /lib64/libpthread.so.0
#1 0x00007f0cb60dae69 in gtm_dump_core () from /Data/VistA/Production/m/libyottadb.so
#2 0x00007f0cb60db228 in gtm_fork_n_core () from /Data/VistA/Production/m/libyottadb.so
#3 0x00007f0cb5fca075 in generic_signal_handler.8416 () from /Data/VistA/Production/m/libyottadb.so
#4 <signal handler called>
#5 0x00007f0cb4fece10 in __memcpy_ssse3_back () from /lib64/libc.so.6
#6 0x00007f0cb60499e3 in s2pool () from /Data/VistA/Production/m/libyottadb.so
#7 0x00007f0cb5e57b32 in ydb_incr_s () from /Data/VistA/Production/m/libyottadb.so
#8 0x0000000000413b23 in parse_literal_to_parameter ()
#9 0x0000000000422ab5 in yyparse ()
#10 0x0000000000412c6d in parse_line ()
#11 0x0000000000419a7c in run_query ()
#12 0x0000000000405a52 in main ()
There are 2 issues.
-
YDB issue :
ydb_incr_s.c
was modified as part of YottaDB/DB/YDB@623dc00d to do as2pool()
invocation on the return value ofop_add()
. While this is the right thing to do in case the mval returned byop_add()
has theMV_STR
bit set, it is not the right thing to do in case the mval does not have theMV_STR
bit set. Invokings2pool()
on an mval that represents a pure number (MV_INT
orMV_NM
bits are set butMV_STR
bit is not set in themvtype
member) implies we could be looking at garbage values instr.len
andstr.addr
and trying to move that to the stringpool which could cause a SIG-11. This is tracked by YottaDB/DB/YDB#633 (closed). -
YDBOcto issue : Currently we do no cleanup of the local variable tree
%ydboctocursor(CURSORID,"parameters",...)
(corresponding to the parameter list of the current query) and this can cause a process to unnecessarily bloat its memory use as it executes a lot of queries in its lifetime. We can avoid the YDB issue in YDBOcto by ensuring that we do not accumulate a lot of parameters from prior completed queries in the local variable tree. This is what eventually (with lots of queries executed) causes reuse of memory locations resulting in garbage values instr.addr
andstr.len
that result in the SIG-11.
Note that cleaning up the %ydboctocursor(CURSORID,"parameters",...)
subtree is likely to fix most of the issues that a user is likely to encounter but the complete fix will happen only when the YDB issue is also fixed.