Bug #91851 FTS query with limit and mecab in file fts0que.cc line 3560
Submitted: 1 Aug 2018 11:04 Modified: 2 Sep 2018 12:15
Reporter: Nikolai Ikhalainen Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server: FULLTEXT search Severity:S3 (Non-critical)
Version:5.7.23 OS:Any
Assigned to: CPU Architecture:Any

[1 Aug 2018 11:04] Nikolai Ikhalainen
Description:
2018-08-01T10:47:11.572425Z 0 [ERROR] Incorrect definition of table performance_schema.global_variables: expected column 'VARIABLE_VALUE' at position 1 to have type varchar(1024), found type varchar(2048).
2018-08-01T10:47:11.572932Z 0 [Note] mysqld: ready for connections.
Version: '5.7.23'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server (GPL)
2018-08-01T10:47:35.616440Z 2 [Warning] InnoDB: Table mysql/innodb_table_stats has length mismatch in the column name table_name.  Please run mysql_upgrade
2018-08-01T10:47:35.616481Z 2 [Warning] InnoDB: Table mysql/innodb_index_stats has length mismatch in the column name table_name.  Please run mysql_upgrade
2018-08-01 10:47:35 0x7f5d97aff700  InnoDB: Assertion failure in thread 140039953577728 in file fts0que.cc line 3560
InnoDB: Failing assertion: ret == 0
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
10:47:35 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.

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

Thread pointer: 0x7f5d64000ae0
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 = 7f5d97afee80 thread_stack 0x40000
mysqld(my_print_stacktrace+0x2c)[0x563d4339ea6c]
mysqld(handle_fatal_signal+0x479)[0x563d42cca709]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7f5db05200c0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7f5daecacfff]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f5daecae42a]
mysqld(+0x628c7b)[0x563d42ca0c7b]
mysqld(fts_query(trx_t*, dict_index_t*, unsigned int, unsigned char const*, unsigned long, fts_result_t**, unsigned long long)+0x24b2)[0x563d4366a452]
mysqld(ha_innobase::ft_init_ext(unsigned int, unsigned int, String*)+0x1df)[0x563d433dd80f]
mysqld(Item_func_match::init_search(THD*)+0x465)[0x563d42d85195]
mysqld(init_ftfuncs(THD*, st_select_lex*)+0x40)[0x563d43119b00]
mysqld(JOIN::optimize()+0x2daa)[0x563d4316522a]
mysqld(st_select_lex::optimize(THD*)+0x692)[0x563d431a90e2]
mysqld(handle_query(THD*, LEX*, Query_result*, unsigned long long, unsigned long long)+0x20c)[0x563d431a935c]
mysqld(+0x61ccb2)[0x563d42c94cb2]
mysqld(mysql_execute_command(THD*, bool)+0x47eb)[0x563d4316cf5b]
mysqld(mysql_parse(THD*, Parser_state*)+0x395)[0x563d4316f585]
mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0xfc4)[0x563d43170644]
mysqld(do_command(THD*)+0x197)[0x563d43171a17]
mysqld(handle_connection+0x270)[0x563d4322e3d0]
mysqld(pfs_spawn_thread+0x1b4)[0x563d43705494]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7494)[0x7f5db0516494]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f5daed62acf]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f5d64005640): 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.
[1 Aug 2018 13:18] Sinisa Milivojevic
Hi,

This seems like a possible bug.

But, before we proceed any further, let me tell you that there have been some changes in MySQL data formats. 

Hence, did you run mysql_upgrade after installing 5.7.23 ???

If not, please do that first and then let us know if crashes continue !!!!

Thanks in advance.
[1 Aug 2018 16:37] Nikolai Ikhalainen
> Hence, did you run mysql_upgrade after installing 5.7.23 ???

I've executed mysql_upgrade (it shows OK for problematic table) and restarted mysqld. It resolves the issue with wrong column length for system tables, but select ... match against ... limit 40,40 still crashes database.

The problem could be resolved by table rebuild with: mysqldump db | mysql test
select against db still causing crash and select against test finishes normally.
[2 Aug 2018 12:15] Sinisa Milivojevic
Hi,

This looks like a bug to me.

But, in order to verify the bug report, we need a repeatable test case. We need a table with a minimal set of rows and a query that will always, or sometimes, crash the server.

You can upload the table to this report, by using "Files" tab. That file will be visible only by us who work at Oracle.

Thanks in advance.
[3 Sep 2018 1:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".