Рандомный краш при использовании UDF функции

[Romchegzap]

Describe the bug
Мантикора крашится рандомно(на 1-5 вызов запроса) с использованием UDF функции. Для чистоты эксперимента - функция принимает несколько параметров но возвращает всегда единицу. В мантикоре порядка 230тыс продуктов.

В нормальном виде функция содержит внутри несколько вложенных циклов и подключена либа cJSON для перебора json по ключам и фильтрации массива обьектов. А вот упрощенный вариант

#include "sphinxudf.h"  
#include <stdlib.h>  
#include <string.h>  
#include <stdio.h>  
#include <stdbool.h>    
  
int json_filter_bool_ver()  
{  
    return SPH_UDF_VERSION;  
}  
  
int json_filter_bool_init ( SPH_UDF_INIT *init, SPH_UDF_ARGS *args, char *error_message )  
{  
    return 0;  
}  
  
sphinx_int64_t json_filter_bool ( SPH_UDF_INIT *init, SPH_UDF_ARGS * args, int *length, char *error_flag )  
{  
    return 1;  
}  
  
void json_filter_bool_deinit(SPH_UDF_INIT * init)   
{  
  
}  

Запрос

SELECT id, JSON_FILTER_BOOL(matchings_data.competitors, '{"domain_id":[22]}') as a   
FROM products_rt WHERE id = 970745  

или еще можно использовать алиас с селекта в WHERE тогда вообще на 1-2 попытке крашится

SELECT id, JSON_FILTER_BOOL(matchings_data.competitors, '{"domain_id":[22]}') as a   
FROM products_rt WHERE a > 0  

в matchings_data.competitors - у нас json

To Reproduce
Steps to reproduce the behavior:

1. Создать простую функцию - прикреплю ниже.
   Компилирую gcc -shared -fPIC json_filter_bool.c -o json_filter_bool.so
   Заливаю create function JSON_FILTER_BOOL returns integer soname 'json_filter_bool.so';
2. Вызвать запрос с этой функцией несколько раз

Expected behavior
Вывод результатов запроса без крашей.

Describe the environment:

• Manticore 5.0.2 348514c86@220530 dev
• Linux roma 5.4.0-66-generic #74~18.04.2-Ubuntu SMP Fri Feb 5 11:17:31 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Messages from log files:
Прикреплю всё что собрал(только в searchd.log не подтягиваются дебаг символы, хотя они есть, не знаю в чём причина, в gdb всё отлично)

Additional context
manticore_logs.tar.gz

[Romchegzap]

Добавил тестовые данные на ftp(github-issue-815)

[sanikolaev]

Из слака:

На 3.6.0 работает! Проверил сразу и на функции с возвратом единицы и на функции для фильтрации json, ничего не крашится

[githubmanticore]

➤ Aleksey N. Vinogradov commented:

по нашим dev-билдам прошёлся ручным бисектом.

• Manticore 4.2.1 5c1b715b1@220221 release - good
• Manticore 4.2.1 7b41f5cf8@220302 release - bad

Картинка из гитлога с этими ревизиями:

Наверное, good можно поднять ещё на пару вверх (вряд ли коммиты в доку могли бы поломать udf).

[githubmanticore]

➤ Aleksey N. Vinogradov commented:

Still reproducible with 01ecfecc right over 61c90e4d (that is - cherry-picked)

nosync

#14 0x00007f3093600859 in __GI_abort () at abort.c:79 
#15 0x00007f309366b26e in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f3093795298 "%s\n") at ../sysdeps/posix/libc_fatal.c:155 
#16 0x00007f30936732fc in malloc_printerr (str=str@entry=0x7f3093797278 "malloc_consolidate(): invalid chunk size") at malloc.c:5347 
#17 0x00007f3093673ad8 in malloc_consolidate (av=av@entry=0x7f308c000020) at malloc.c:4477 
#18 0x00007f3093675c83 in _int_malloc (av=av@entry=0x7f308c000020, bytes=bytes@entry=10248) at malloc.c:3699 
#19 0x00007f3093678299 in __GI___libc_malloc (bytes=10248) at malloc.c:3066 
#20 0x00007f30938b8b39 in operator new(unsigned long) () from /lib/x86_64-linux-gnu/libstdc++.so.6 
#21 0x000000000045f84d in sph::DefaultStorage_T<SqlStmt_t>::Allocate (iLimit=8) at /sphinx/sphinxfrommac/src/std/storage.h:33 
#22 sph::Vector_T<SqlStmt_t, sph::DefaultCopy_T<SqlStmt_t>, sph::DefaultRelimit, sph::DefaultStorage_T<SqlStmt_t> >::DiscardAndReserve (this=this@entry=0x7f3068020ba0, iDiscard=iDiscard@entry=0, iNewLimit=<optimized out>) at /sphinx/sphinxfrommac/src/std/vector_impl.h:247 
#23 0x000000000044d773 in sph::Vector_T<SqlStmt_t, sph::DefaultCopy_T<SqlStmt_t>, sph::DefaultRelimit, sph::DefaultStorage_T<SqlStmt_t> >::Reserve (this=0x7f3068020ba0, iNewLimit=0) at /sphinx/sphinxfrommac/src/std/vector_impl.h:264 
#24 sph::Vector_T<SqlStmt_t, sph::DefaultCopy_T<SqlStmt_t>, sph::DefaultRelimit, sph::DefaultStorage_T<SqlStmt_t> >::Add<sph::DefaultStorage_T<SqlStmt_t> > (this=0x7f3068020ba0, tValue=...) at /sphinx/sphinxfrommac/src/std/vector_impl.h:97 
#25 SqlParserTraits_c::PushQuery (this=this@entry=0x7f3068020aa0) at /sphinx/sphinxfrommac/src/searchdsql.cpp:78 
#26 0x0000000000452036 in SqlParser_c::PushQuery (this=this@entry=0x7f3068020aa0) at /sphinx/sphinxfrommac/src/searchdsql.cpp:280 
#27 0x0000000000455e38 in SqlParser_c::SqlParser_c (this=this@entry=0x7f3068020aa0, dStmt=..., eCollation=SPH_COLLATION_LIBC_CI, szQuery=szQuery@entry=0x7f308c026b70 "SELECT id, JSON_FILTER_BOOL(matchings_data.competitors, '{\"domain_id\":[22]}') as a FROM products_index WHERE a > 0", pError=pError@entry=0x7f3068022ff8) at /sphinx/sphinxfrommac/src/searchdsql.cpp:262 
#28 0x00000000004573ec in sphParseSqlQuery (sQuery=sQuery@entry=0x7f308c026b70 "SELECT id, JSON_FILTER_BOOL(matchings_data.competitors, '{\"domain_id\":[22]}') as a FROM products_index WHERE a > 0", iLen=iLen@entry=114, dStmt=..., sError="", eCollation=<optimized out>) at /sphinx/sphinxfrommac/src/searchdsql.cpp:1437 
#29 0x00000000004c59ef in ClientSession_c::Execute (this=0x7f3068022ff8, sQuery=..., tOut=...) at /sphinx/sphinxfrommac/src/searchd.cpp:16007 
#30 0x00000000004cc8bf in session::Execute (sQuery={...}, tOut=...) at /sphinx/sphinxfrommac/src/searchd.cpp:16458 
#31 0x000000000046ec28 in (anonymous namespace)::LoopClientMySQL (uPacketID=@0x7f3068021e57: 1 '%CODE_BLOCK%1', iPacketLen=115, pProfile=0x0, pBuf=0x7f3068000ca0) at /sphinx/sphinxfrommac/src/netreceive_ql.cpp:871 
#32 SqlServe (pBuf=...) at /sphinx/sphinxfrommac/src/netreceive_ql.cpp:1105 

[sanikolaev]

We could reproduce the crash in an old version, but can't reproduce it in the latest commit. So we can consider this is fixed. Please reopen in case you can still reproduce the crash.