Segfault with more than 6 key/value components

[wildbiotiger]

It may be that I have some configuration wrong, but when I configure a table with a combination of 7 keys and values, the application segfaults on the first sp_set().

for example, add 4 new values to the example/multipart.c db declaration, and attempt to run the application:

        sp_setstring(env, "db.test.scheme", "key_i", 0);
        sp_setstring(env, "db.test.scheme", "key_j", 0);
        sp_setstring(env, "db.test.scheme", "key_k", 0);
        sp_setstring(env, "db.test.scheme", "a", 0);
        sp_setstring(env, "db.test.scheme", "b", 0);
        sp_setstring(env, "db.test.scheme", "c", 0);
        sp_setstring(env, "db.test.scheme", "d", 0);
        sp_setstring(env, "db.test.scheme.key_i", "u32,key(0)", 0);
        sp_setstring(env, "db.test.scheme.key_j", "u32,key(1)", 0);
        sp_setstring(env, "db.test.scheme.key_k", "u32,key(2)", 0);
        sp_setstring(env, "db.test.scheme.a", "u32", 0);
        sp_setstring(env, "db.test.scheme.b", "u32", 0);
        sp_setstring(env, "db.test.scheme.c", "u32", 0);
        sp_setstring(env, "db.test.scheme.d", "u32", 0);

for me, this results in the following message:
Segmentation fault (core dumped)
with the GDB output below:

GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./multipart...done.
(gdb) r
Starting program: /home/.../sophia/example/multipart 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xb7d6cb40 (LWP 10406)]
[New Thread 0xb756bb40 (LWP 10407)]
[New Thread 0xb69ffb40 (LWP 10408)]
[New Thread 0xb61feb40 (LWP 10409)]
[New Thread 0xb59fdb40 (LWP 10410)]
[New Thread 0xb4dffb40 (LWP 10411)]

Thread 1 "multipart" received signal SIGSEGV, Segmentation fault.
__memcpy_sse2_unaligned () at ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:651
651	../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S: No such file or directory.
(gdb) bt
#0  __memcpy_sse2_unaligned () at ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:651
#1  0x080514d2 in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) at /usr/include/i386-linux-gnu/bits/string3.h:53
#2  sf_write (dest=0x80a2267 "", v=0x80a2267, s=0x809f684) at sophia/format/sf.h:158
#3  sv_vbuild (r=0x809f6dc, fields=fields@entry=0x80a219c) at sophia/version/sv_v.h:60
#4  0x08080218 in se_document_create (o=0x80a2170, flags=0 '\000') at sophia/environment/se_document.c:96
#5  0x08080455 in se_dbwrite (db=0x809e5f8, o=0x80a2170, flags=<optimized out>) at sophia/environment/se_db.c:208
#6  0x08080d56 in se_dbset (o=0x809e5f8, v=0x80a2170) at sophia/environment/se_db.c:254
#7  0x080833b5 in sp_set (ptr=0x809e5f8, ptr_arg=0x80a2170) at sophia/sophia/sophia.c:180
#8  0x08049b3e in main (argc=1, argv=0xbffff094) at multipart.c:58
(gdb) 

If there's a configuration option I'm missing, I'm happy to close this issue, but the error seems a little obtuse. Any suggestions are welcome.

[pmwkaa]

thanks, I'll take a look when I got free minute :)

[pmwkaa]

I've made a small test trying to reproduce the problem, but it looks like it is working. Basically there are limit of 8 fields at the moment, but it should not result in crash anyway.

[wildbiotiger]

Hmmm, interesting, I'm curious if my dev env is missing something. Seems a bit odd to fail there, but I understand the limitation. Would it be possible to update the documentation to be more explicit about composite/multivariable keys?

Also - side question, how fault-tolerant is SophiaDB with respect to sudden power-offs and brownouts? Is there any chance for data corruption or options for recovery from a bad DB state?