UTF-8 mode $TRANSLATE() with multi-byte string literals as the second or third parameter works correctly when executed from shared library
Final Release Note
When executed from a routine in a shared library, $TRANSLATE() in UTF-8 mode works correctly when the second or third arguments are multi-byte literals. In YottaDB r1.26 and r1.28, this could result in abnormal process termination with a segmentation violation (SIGSEGV). [#492 (closed)]
Description
Below is the original issue report from @ztmr. See #492 (comment 346994360) for a simple test case and description of the circumstances surrounding the SIG-11.
What we know so far:
- everything works fine with all the individual
.o
routines (without source available) - we haven't seen this problem in local Docker environments (using
.so
library) - most of the calls work with
.so
as well but some calls simply crash on the following error (this is within the same routine) - we observe this in a Kubernetes environment, not sure how this could be related though
- no difference in behaviour if we keep
.so
and individual.o
files in the$zroutines
search path as a fallback - the
.so
is produced usinggcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
(the officialyottadb/yottadb:r1.28
Docker image) using the following command:gcc -shared -o libmyappcore.so -o _MYAPP*.o
- we may need to re-try this with debug build since most of the information was optimized out
Program received signal SIGSEGV, Segmentation fault.
#0 activate_hashtab_in_buffer_int4 (copy_entry_from_buffer=0x0, buffer=0x7ffff2fc0a45 <_MYAPPSRV+80181> "") at /tmp/yottadb-src/sr_port/hashtab_implementation.h:790
#1 op_fntranslate_fast (src=0x5555555dc210, rplc=0x5555558ce3b0, m_xlate=0x5555558ce370, m_xlate_hash=0x5555558ce390, dst=0x5555555dc1f0) at /tmp/yottadb-src/sr_port/op_fntranslate.c:168
#2 0x00007ffff2faf0d4 in _MYAPPSRV () from /opt/myapp/rtns/core/libmyappcore.so
[...]
#21 0x00007ffff74919c8 in ?? () from /opt/yottadb/current/libyottadb.so
#22 0x0000000000000000 in ?? ()
Edited by K.S. Bhaskar