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

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.