MySQL Bugs: #3870: Crash on FTS query

Bug #3870	Crash on FTS query
Submitted:	24 May 2004 5:55	Modified:	18 Jun 2004 13:20
Reporter:	Steven Roussey	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: MyISAM storage engine	Severity:	S1 (Critical)
Version:	4.0.20	OS:
Assigned to:		CPU Architecture:	Any

Description:
Crashes on query

How to repeat:
bug_report_1.tar.gz in ftp secret folder. SQL for crash is in error log file.

Suggested fix:
?

The table is fine according to 'check table the_table_name'. The select crashes it. The select also crashes it in older versions of myslq!! Doing a repair in the old version and then doing the select in the old version is OK. That is why I came to the conclusion that the file is corrupt. CHECK TABLE does not find the corruption, however.

Another note on this: The tables I had the most problems with had FTS indicies. I can't say that it is more than coincidental just yet. I am not conclusive that it is a cause and effect relationship at this time.

Even returning to the older versions of mysql is not getting rid of all our problems (we are seeing extremely high loads on the same stream of queries as usual). Selectively repairing tables has helped. It may be that it is not FTS related and we should repair all tables.

Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

got it now, thanks.
It's your bug#2708 which was fixed in 4.1 tree only.
Actually there is another bugfix required ("phase search" match "paraphrase searches" - that is, don't respect word boundaries) for this crash to be visible.

In 4.0.20 I ported bugfix for the latter bug from 4.1.2 to 4.0.20 :(
Ok, I'm backporintg the fix for bug#2708 now.

just to clarify - the crash was caused by a double quote in the query string (like MATCH ... AGAINST (' some " query' IN BOOLEAN MODE) ) that did not have a matching closing double quote.

-- Log info -- 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x84ca310 = SELECT * FROM partall WHERE    MATCH
(partsno,description,mfg) AGAINST(' +19"* +TFT*' IN BOOLEAN MODE) AND mfg LIKE
'%%%%' AND spe
thd->thread_id=48496

Anyway the following query crashes the system
SELECT * FROM partall WHERE    MATCH (partsno,description,mfg) AGAINST(' +22"*
+inch*' IN BOOLEAN MODE) AND mfg LIKE '%%%%' AND special LIKE '%%%%'  LIMIT 250

I have tried multiple formats of the search and found that its the " in the
AGAINST statement that causes the problem, I found multiple times mysql auto
recovered due to this, only noticed it today because the mysql failed to auto
restart

Stack trace
0x80720d4 handle_segfault + 420
0x8250d48 pthread_sighandler + 184
0x822b51d _ftb_strstr + 61
0x822b6ea _ftb_climb_the_tree + 202
0x822bd9d ft_boolean_find_relevance + 509
0x822bb25 ft_boolean_read_next + 837
0x80caf34 ft_read__9ha_myisamPc + 52
0x80a0545 join_ft_read_first__FP13st_join_table + 53
0x809f516 sub_select__FP4JOINP13st_join_tableb + 86
0x809f2b3 do_select__FP4JOINPt4List1Z4ItemP8st_tableP9Procedure + 403
0x8097778
mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8st_orderT4T3T4UlP13sel
ect_result + 7000
0x8095be6 handle_select__FP3THDP6st_lexP13select_result + 102
0x807cfd2 mysql_execute_command__Fv + 1026
0x8080935 mysql_parse__FP3THDPcUi + 149
0x807c113 dispatch_command__F19enum_server_commandP3THDPcUi + 1443
0x807bb5e do_command__FP3THD + 158
0x807b388 handle_one_connection + 648
0x824e4fc pthread_start_thread + 220
0x828452a thread_start + 4

How to repeat:
Run the following query format
SELECT * FROM partall WHERE    MATCH (partsno,description,mfg) AGAINST(' +22"*
+inch*' IN BOOLEAN MODE) AND mfg LIKE '%%%%' AND special LIKE '%%%%'  LIMIT 250

Make +22" = +22 and the crash goes away

Suggested fix:

Is this bug also present in 3.23?

bye,

-christian- <ch@debian.org>