Uploaded image for project: 'Percona Server'
  1. Percona Server
  2. PS-4640

FTS query with limit and mecab in file fts0que.cc line 3560

    Details

    • Type: Bug
    • Status: Done
    • Priority: Medium
    • Resolution: Fixed
    • Affects Version/s: 5.7.22-22
    • Fix Version/s: 5.7.25-28, 8.0.15-5
    • Component/s: None
    • Labels:

      Description

      InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
      InnoDB: about forcing recovery.
      01:11:04 UTC - mysqld got signal 6 ;
      This could be because you hit a bug. It is also possible that this binary
      or one of the libraries it was linked against is corrupt, improperly built,
      or misconfigured. This error can also be caused by malfunctioning hardware.
      Attempting to collect some information that could help diagnose the problem.
      As this is a crash and something is definitely wrong, the information
      collection process might fail.
      Please help us make Percona XtraDB Cluster better by reporting any
      bugs at https://jira.percona.com/projects/PXC/issues

      key_buffer_size=8388608
      read_buffer_size=131072
      max_used_connections=57
      max_threads=1003
      thread_count=25
      connection_count=8
      It is possible that mysqld could use up to
      key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 214900 K bytes of memory
      Hope that's ok; if not, decrease some variables in the equation.

      Thread pointer: 0x7f2d78081080
      Attempting backtrace. You can use the following information to find out
      where mysqld died. If you see no messages after this, something went
      terribly wrong...
      stack_bottom = 7f2d57b6c930 thread_stack 0x40000
      /usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xf2e19b]
      /usr/sbin/mysqld(handle_fatal_signal+0x471)[0x7a7171]
      /lib64/libpthread.so.0(+0xf370)[0x7f2fc6f47370]
      /lib64/libc.so.6(gsignal+0x37)[0x7f2fc50521d7]
      /lib64/libc.so.6(abort+0x148)[0x7f2fc50538c8]
      /usr/sbin/mysqld[0x76fec6]
      /usr/sbin/mysqld(_Z9fts_queryP5trx_tP12dict_index_tjPKhmPP12fts_result_ty+0x1b02)[0x12efd72]
      /usr/sbin/mysqld(_ZN11ha_innobase11ft_init_extEjjP6String+0x64d)[0x1037cfd]
      /usr/sbin/mysqld(_ZN15Item_func_match11init_searchEP3THD+0x121)[0x89b831]
      /usr/sbin/mysqld(_Z12init_ftfuncsP3THDP13st_select_lex+0x40)[0xc96810]
      /usr/sbin/mysqld(_ZN4JOIN8optimizeEv+0x28b5)[0xce6d45]
      /usr/sbin/mysqld(_ZN13st_select_lex8optimizeEP3THD+0x6a5)[0xd317a5]
      /usr/sbin/mysqld(_Z12handle_queryP3THDP3LEXP12Query_resultyy+0x155)[0xd31985]
      /usr/sbin/mysqld[0x761661]
      /usr/sbin/mysqld(_Z21mysql_execute_commandP3THDb+0x7362)[0xcf2be2]
      /usr/sbin/mysqld(_Z11mysql_parseP3THDP12Parser_state+0x655)[0xcf4125]
      /usr/sbin/mysqld[0xcf42cb]
      /usr/sbin/mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x1162)[0xcf5e72]
      /usr/sbin/mysqld(_Z10do_commandP3THD+0x18a)[0xcf7b8a]
      /usr/sbin/mysqld(handle_connection+0x2e8)[0xdc32a8]
      /usr/sbin/mysqld(pfs_spawn_thread+0x1b4)[0xfb2fe4]
      /lib64/libpthread.so.0(+0x7dc5)[0x7f2fc6f3fdc5]
      /lib64/libc.so.6(clone+0x6d)[0x7f2fc511476d]

      select <fields removed> from i where match(i.n) against('<japanese utf8 text removed>' in boolean mode) limit 40, 40

       

      create table i (
      sid varchar(255) NOT NULL,
      `id` varchar(255) NOT NULL,
      ...
      n varchar(255) DEFAULT NULL,
      ...
      PRIMARY KEY (`storeid`,`id`),
      FULLTEXT KEY `n_idx` (`n`) /*!50100 WITH PARSER `mecab` */) ENGINE=InnoDB DEFAULT CHARSET=utf8;

      How to repeat:
      I'm getting crashes in production environment without possibility to repeat it on a simpler dataset or table structure. If the table reloaded with mysqldump mysqld is not crashing. It's also possible what server wasn't properly upgraded.

      There is no crash if limit clause omitted.

        Smart Checklist

          Attachments

            Activity

              People

              • Assignee:
                sergei.glushchenko Sergei Glushchenko
                Reporter:
                nickolay.ihalainen Nickolay Ihalainen
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 4 days, 1 hour, 59 minutes
                  4d 1h 59m