On Monday 04 February 2002 07:33 pm, [EMAIL PROTECTED] wrote:
> Version: 4.0.1 binary distro(I have gcc 2.96, so I'm using your prebuilt
one)
> Synopsis: Upon executing a query using the MATCH() clause with FULLTEXT
indicies,
> it will crash the mysqld daemon.
Thanks for the bug report. I am forwarding this to Sergei, our developer
responsbile for full-text.
>
> The query that does this is a "multi table" query, as such..
>
> MATCH(table1.col1, table2.col2) AGAINST ('foo')
>
> This will happen with or without the IN BOOLEAN MODE clause.
> mysqld_safe will crash, and restart.
> I understand that cross-table MATCHes are a limitation of FULLTEXT
searches, which
> is referenced in the manual if the "IN BOOLEAN MODE" is left out. However,
it
> will blow either way.
>
> Using single table queries with/without the IN BOOLEAN MODE clause work
fine, the
> problem only seems to appear when doing multi-table MATCHes.
>
> It (the database) was previously 3.23 and all I've done was replace the
binaries. "normal"
> queries work okay thus far, but I've only had it a couple of hours.
>
> Hope the logs help. email me if I can be of more use.
> This appears fairly easy to reproduce, but if you REALLY want a testcase,
let me know
> and I'll post one to [EMAIL PROTECTED]
>
> -Mike
> [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------------------------------
> 0x807db7f handle_segfault__Fi + 383
> 0x823d64a pthread_sighandler + 154
> 0x8053a24 val__15Item_func_match + 72
> 0x80555bc val_str__14Item_real_funcP6String + 20
> 0x804a979 send__4ItemP3THDP6String + 73
> 0x8075afe send_data__11select_sendRt4List1Z4Item + 98
> 0x80a6e5c end_send__FP4JOINP13st_join_tableb + 112
> 0x80a6337 do_select__FP4JOINPt4List1Z4ItemP8st_tableP9Procedure + 327
> 0x809f5e4
mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8st_orderT4P4ItemT4UlP13select_result
+ 6548
> 0x80ac1c0 handle_select__FP3THDP6st_lexP13select_result + 96
> 0x8085b4b mysql_execute_command__Fv + 959
> 0x808a262 mysql_parse__FP3THDPcUi + 270
> 0x8084e57 dispatch_command__F19enum_server_commandP3THDPcUi + 1319
> 0x808a694 do_command__FP3THD + 88
> 0x8084296 handle_one_connection__FPv + 546
>
---------------------------------------------------------------------------------------------
> [root@dev init.d]# my
> Reading table information for completion of table and column names
> You can turn off this feature to get a quicker startup with -A
>
> Welcome to the MySQL monitor. Commands end with ; or \g.
> Your MySQL connection id is 1 to server version: 4.0.1-alpha
>
> Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
>
> mysql> SELECT (MATCH(Merchants.MerchantName, ContactInfos.Address) AGAINST
('ferguson' IN BOOLEAN MODE)) AS RANKING
> -> FROM Merchants,ContactInfos, MerchantLocations
> -> WHERE MerchantLocations.LocationID = 20083 AND
> -> Merchants.MerchantID = MerchantLocations.MerchantID AND
> -> ContactInfos.ContactInfoID = MerchantLocations.LocationID AND
> -> (MATCH(Merchants.MerchantName, ContactInfos.Address) AGAINST
('ferguson' IN BOOLEAN MODE))
> -> ORDER BY Ranking DESC
> -> ;
> ERROR 2013: Lost connection to MySQL server during query
> mysql>
> Number of processes running now: 0
> 020204 18:26:21 mysqld restarted
>
> mysql> quit
>
---------------------------------------------------------------------------------------------
> 020204 18:26:01 mysqld started
> 020204 18:26:01 InnoDB: Started
> /usr/local/mysql/bin/mysqld: ready for connections
> mysqld got signal 11;
> 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.
> We will try our best to scrape up some info that will hopefully help
diagnose
> the problem, but since we have already crashed, something is definitely
wrong
> and this may fail.
>
> key_buffer_size=8388600
> record_buffer=131072
> sort_buffer=2097144
> max_used_connections=0
> max_connections=100
> threads_connected=1
> It is possible that mysqld could use up to
> key_buffer_size + (record_buffer + sort_buffer)*max_connections = 225791 K
> bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
>
> 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 range sanity check OK, backtrace follows:
> 0x807db7f
> 0x823d64a
> 0x8053a24
> 0x80555bc
> 0x804a979
> 0x8075afe
> 0x80a6e5c
> 0x80a6337
> 0x809f5e4
> 0x80ac1c0
> 0x8085b4b
> 0x808a262
> 0x8084e57
> 0x808a694
> 0x8084296
> Stack trace seems successful - bottom reached
> Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow
instructions on how to resolve the stack trace. Resolved
> stack trace is much more helpful in diagnosing the problem, so please do
> resolve it
> Trying to get some variables.
> Some pointers may be invalid and cause the dump to abort...
> thd->query at 0x841c478 = SELECT (MATCH(Merchants.MerchantName,
ContactInfos.Address) AGAINST ('ferguson' IN BOOLEAN MODE)) AS
> RANKING
> FROM Merchants,ContactInfos, MerchantLocations
> WHERE MerchantLocations.LocationID = 20083 AND
> Merchants.MerchantID = MerchantLocations.MerchantID AND
> ContactInfos.ContactInfoID = MerchantLocations.LocationID AND
> (MATCH(Merchants.MerchantName, ContactInfos.Address) AGAINST
('ferguson' IN BOOLEAN MODE))
> ORDER BY Ranking DESC
> thd->thread_id=1
>
> Successfully dumped variables, if you ran with --log, take a look at the
> details of what thread 1 did to cause the crash. In some cases of really
> bad corruption, the values shown above may be invalid.
>
> The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
> information that should help you find out what is causing the crash.
>
> Number of processes running now: 0
> 020204 18:26:21 mysqld restarted
> 020204 18:26:21 InnoDB: Started
> /usr/local/mysql/bin/mysqld: ready for connections
>
>
>
>
--
MySQL Development Team
For technical support contracts, visit https://order.mysql.com/
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sasha Pachev <[EMAIL PROTECTED]>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/
/_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA
<___/
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
