FATAL CRASH при работе about manticoresearch

[tomatolog]

воспроизвел на таких данных из test_117

sphinxql-5> UPDATE rt_mva SET mva1 = () WHERE id<400;

sphinxql-6> SELECT GREATEST(mva1) FROM rt_mva WHERE id<203;
ERROR 2006: MySQL server has gone away

[tomatolog]

I fixed the crash with empty MVA array at 1ba915c

You need to install package from the dev repo when CI finishes that build to get this crash fixed.

[srgtest]

backup индекса products и логи (searchd.log, query.log) загрузил на S3: issue-2332

[tomatolog]

проверил запросы из search.log против индекса который вы залили
и все запросы из crash log при проигрывании ругаются на неизвестную колонку product_collection_id_list а некоторые на еще несколько неизвестных колонок - очевидно что индекс не тот же самый который был в момент выполнения этих запросов.

Если я удаляю эти колонки из запросов - то запросы отрабытывают успешно, я не вижу ни одного креша.

Мне нужен воспроизводимый кейс: индекс на котором крешится запрос, запрос который приводит к крешу.
Пока, что я вижу что все нормально работает и расследовать нечего.

[srgtest]

По ошибке загрузил старый backup.
Загрузил актуальный после crash - backup-20240626082242.tar.gz
Запрос прям из лога:

--- crashed SphinxQL request dump ---
SELECT
    id,
    name,
    slug,
    image,

    price_retail,
    price_discounted_for_guest,

    price_discount_percent_for_guest,
    price_discounted_for_authorized,
    price_discount_percent_for_authorized,

    price_discounted_for_subscriber,
    price_discount_percent_for_subscriber,


    marketing_status_list,

    IF (
        availability_status != 40 AND availability_status 
!= 50 AND GREATEST(shop_id_list) > 0,
        20,
        availability_status
    
) as availability_status,
    availability_status as availability_status_online,
 
   availability_quantity,
    GREATEST(shop_id_list) > 0 as is_available_offline,

    IN(city_id_list, -1) as is_available_in_customer_city,
    IN(shop_id_list, -1) 
as is_available_in_customer_shop,
    IF (
        availability_status IN (40, 50),

        100,
        IF (
            IN(shop_id_list, -1),
            35,
     
       IF (
                IN(city_id_list, -1),
                30,
            
    IF (
                    GREATEST(shop_id_list) > 0,
                    20,
 
                   availability_status
                )
            )
        )
 
   ) as availability,  /* статус для сортировки */

    vendor_id,

    nds,

    main_category_id_list,
    author_id_list,

    product_type_id,
  
  article_number_id,
    product_collection_id_list,

    1000000000000 * literature_work_publishing_year 
+ released_at as newness

    , publisher_id, publisher_series_id, tbk_id_list, weight,
height, width, length, literature_work_publishing_year, preorder_available_at, released_at,
 tbk_id_list, weight, height, width, length, binding_id, printing_page_count, printing_page_format,
 printing_copy_count
    
FROM products
WHERE ALL(tbk_id_list) NOT IN (32, 30) AND 
ANY(shop_id_list) IN (0) AND availability_status = 50
ORDER BY availability DESC, 
purchase_stats_day_avg_count DESC, newness DESC, price_retail ASC
LIMIT 40
OFFSET 
0
OPTION
    max_matches = 40
--- request dump end ---

[tomatolog]

tried index you provided at the backup-20240626082242.tar.gz along with the queries at the search.log you provided and query above and for me all works fine for either 6.3.0 1811a9efb@24052209 or 6.2.12 dc5144d35@230822

I need reproducible example to investigate this crashes further.

Could you after the crash copy the index mention at the crash log at the line

--- local index:

to the test box there run daemon the same version as daemon that cause that crash and send the query from the crash log. Then if daemon crashed upload the index and searchd.log with the query cause that crash.

[srgtest]

Не могли бы вы после сбоя скопировать упоминание индекса в журнале сбоев в строке

По логу это всегда

 --- local index:products

Затем, если демон вышел из строя, загрузите индекс и файл searchd.log с запросом, вызывающим сбой.

Как раз данные после этого были предоставлены: backup индекса products и логи.
Не знаю даже как еще это можно воспроизвести.

[sanikolaev]

У меня тоже не воспроизводится:

snikolaev@dev2:~/issue-2332/mnt/backup/backup-20240626082242$ while true; do mysql -P9315 -h0 -e "SELECT id, name, slug, image, price_retail, price_discounted_for_guest, price_discount_percent_for_guest, price_discounted_for_authorized, price_discount_percent_for_authorized, price_discounted_for_subscriber, price_discount_percent_for_subscriber, marketing_status_list, IF ( availability_status != 40 AND availability_status != 50 AND GREATEST(shop_id_list) > 0, 20, availability_status ) as availability_status, availability_status as availability_status_online, availability_quantity, GREATEST(shop_id_list) > 0 as is_available_offline, IN(city_id_list, -1) as is_available_in_customer_city, IN(shop_id_list, -1) as is_available_in_customer_shop, IF ( availability_status IN (40, 50), 100, IF ( IN(shop_id_list, -1), 35, IF ( IN(city_id_list, -1), 30, IF ( GREATEST(shop_id_list) > 0, 20, availability_status ) ) ) ) as availability,  /* статус для сортировки */ vendor_id, nds, main_category_id_list, author_id_list, product_type_id, article_number_id, product_collection_id_list, 1000000000000 * literature_work_publishing_year + released_at as newness , publisher_id, publisher_series_id, tbk_id_list, weight, height, width, length, literature_work_publishing_year, preorder_available_at, released_at, tbk_id_list, weight, height, width, length, binding_id, printing_page_count, printing_page_format, printing_copy_count FROM products WHERE ALL(tbk_id_list) NOT IN (32, 30) AND ANY(shop_id_list) IN (0) AND availability_status = 50 ORDER BY availability DESC, purchase_stats_day_avg_count DESC, newness DESC, price_retail ASC LIMIT 40 OFFSET 0 OPTION max_matches = 40;" > /dev/null; echo -n .; done;
.................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................^C...........................^C......^C....^C

Попробуйте сами аналогично. Есть крэш? Если есть, то попробуйте ещё раз, но с отключенной нагрузкой от записи.

[srgtest]

Похоже, что для для mva поля синтаксис позволяет писать пустое значение, отсюда и crash.
Вчера убрали эту запись из доктрины для запроса и со вчерашнего crash новых не было.

[tomatolog]

вы бы кейс выложили чтобы было понятно в чем дело

какой запрос нужен для записи пустого mva атрибута

какой запрос в поиске вызывает креш демона

тк не понятно, почему индекс восстановленный из backup в котором есть все модификации индекса не вызывает креш при поиске

[srgtest]

Спасибо за обратную связь и fix.
Что касается запросов, на котором был crash, то сразу было и не понятно. Тут либо в лог не то попадет либо еще что-то.
Уже только с разработчиком удалось эту гипотезу по mva поля проверить и оказалось в нем дело было.