Bug #3136 memory issues with FTS (and crash report)
Submitted: 10 Mar 2004 16:19 Modified: 13 Sep 2004 19:26
Reporter: Steven Roussey Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server Severity:S1 (Critical)
Version:4.1.2 (bk 9 Mar 04) OS:Linux (RHEL 3)
Assigned to: Assigned Account CPU Architecture:Any

[10 Mar 2004 16:19] Steven Roussey
Description:
The error log:

===============================================
040310 10:16:39  mysqld started
/usr/local/mysql/libexec/mysqld: ready for connections.
Version: '4.1.2-alpha-debug'  socket: '/tmp/mysql.sock'  port: 3306
040310 10:29:01  /usr/local/mysql/libexec/mysqld: Out of memory at line 127, 'net_serv.cc'
040310 10:29:01  /usr/local/mysql/libexec/mysqld: needed 16391 byte (17k), memory in use: -1233107683 bytes (2990098k)
040310 10:29:02  /usr/local/mysql/libexec/mysqld: Out of memory at line 127, 'net_serv.cc'
040310 10:29:02  /usr/local/mysql/libexec/mysqld: needed 16391 byte (17k), memory in use: -1233107683 bytes (2990098k)
040310 10:29:03  /usr/local/mysql/libexec/mysqld: Out of memory at line 127, 'net_serv.cc'
040310 10:29:03  /usr/local/mysql/libexec/mysqld: needed 16391 byte (17k), memory in use: -1233107683 bytes (2990098k)
040310 10:29:07  /usr/local/mysql/libexec/mysqld: Out of memory at line 127, 'net_serv.cc'
040310 10:29:07  /usr/local/mysql/libexec/mysqld: needed 16391 byte (17k), memory in use: -1233107235 bytes (2990098k)
040310 10:29:13  /usr/local/mysql/libexec/mysqld: Out of memory at line 127, 'net_serv.cc'
040310 10:29:13  /usr/local/mysql/libexec/mysqld: needed 16391 byte (17k), memory in use: -1233106787 bytes (2990099k)
040310 10:29:19  /usr/local/mysql/libexec/mysqld: Out of memory at line 127, 'net_serv.cc'
040310 10:29:19  /usr/local/mysql/libexec/mysqld: needed 16391 byte (17k), memory in use: -1233105866 bytes (2990100k)
040310 10:29:19  /usr/local/mysql/libexec/mysqld: Out of memory at line 127, 'net_serv.cc'
040310 10:29:19  /usr/local/mysql/libexec/mysqld: needed 16391 byte (17k), memory in use: -1233105866 bytes (2990100k)
040310 10:29:21  /usr/local/mysql/libexec/mysqld: Out of memory at line 127, 'net_serv.cc'
040310 10:29:21  /usr/local/mysql/libexec/mysqld: needed 16391 byte (17k), memory in use: -1233105866 bytes (2990100k)
040310 10:29:24  /usr/local/mysql/libexec/mysqld: Out of memory at line 127, 'net_serv.cc'
040310 10:29:24  /usr/local/mysql/libexec/mysqld: needed 16391 byte (17k), memory in use: -1233105866 bytes (2990100k)
^G/usr/local/mysql/libexec/mysqld: Out of memory at line 309, 'sql_list.h'
^G/usr/local/mysql/libexec/mysqld: needed 4676 byte (5k), memory in use: -1233105866 bytes (2990100k)

Number of processes running now: 0
040310 10:29:38  mysqld restarted
===============================================

the SQL log file contains stuff like this:

===============================================
040310 11:23:04     257 Connect     apache@morpheus.i on
                    257 Init DB     search
                    257 Query       SELECT title,messageid,rootmessageid,approved,MATCH(title,message,search_forumid) AGAINST ('+fid219380 +(viewsonic g810)' IN BOOLEAN MODE) as score,message as x FROM forums_posts_new_0 WHERE deleted = 'no'  and approved = "yes"  and MATCH (title,message,search_forumid) AGAINST ('+fid219380 +(viewsonic g810)' IN BOOLEAN MODE )  order by messageid desc  limit 0,11
040310 11:23:10     257 Quit
040310 11:23:47     258 Connect     apache@seraph.i on
                    258 Init DB     search
                    258 Query       SELECT title,messageid,approved,MATCH (title,message,search_forumid) AGAINST ('be4him' IN BOOLEAN MODE),message as x FROM forums_posts_new_1 WHERE forumid=3551 and deleted = 'no'  and approved = "yes"  and MATCH (title,message,search_forumid) AGAINST ('be4him' IN BOOLEAN MODE) order by messageid desc limit 0,11

===============================================

How to repeat:
After enough searches are performed, this repeats itself ever couple of hours then needs restarting
[10 Mar 2004 16:21] Steven Roussey
/usr/local/mysql/libexec/mysqld: ready for connections.
Version: '4.1.2-alpha-debug-log'  socket: '/tmp/mysql.sock'  port: 3306
040310 11:52:09  /usr/local/mysql/libexec/mysqld: Out of memory at line 127, 'net_serv.cc'
040310 11:52:09  /usr/local/mysql/libexec/mysqld: needed 16391 byte (17k), memory in use: -1233626215 bytes (2989591k)
040310 11:52:12  Out of memory;  Check if mysqld or some other process uses all available memory. If not you may have to use 'ulimit' to allow mysqld to use more memory or you can add more swap space
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=838860800
read_buffer_size=12578816
max_used_connections=90
max_connections=103
threads_connected=90
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 843360 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0xb38f5f78
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...
Cannot determine thread, fp=0xb532cd48, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x814e4f3 handle_segfault + 455
0x400437ce _end + 934889310
0x818ede3 _ZN13st_join_table7cleanupEv + 15
0x818ef9a _ZN4JOIN9join_freeEb + 224
0x818971d _ZN4JOIN7cleanupEv + 235
0x8189a97 _Z12mysql_selectP3THDPPP4ItemP13st_table_listjR4ListIS1_ES2_jP8st_orderSB_S2_SB_mP13select_resultP18st_select_lex_unitP13st_sel + 663
0x818605b _Z13handle_selectP3THDP6st_lexP13select_result + 247
0x8163420 _Z21mysql_execute_commandP3THD + 4520
0x8167703 _Z11mysql_parseP3THDPcj + 247
0x816142f _Z16dispatch_command19enum_server_commandP3THDPcj + 1673
0x8160d9b _Z10do_commandP3THD + 515
0x81602dc handle_one_connection + 626
0x4003e881 _end + 934869009
0x420e40c7 _end + 969101399
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/en/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 0x8ab0008 = SELECT title,messageid,rootmessageid,approved,MATCH(title,message,search_forumid) AGAINST ('+fid272573 +(SmartLauncher)' IN BOOLEAN MODE) as score,message as x FROM forums_posts_new_3 WHERE deleted = 'no'  and approved = "yes"  and MATCH (title,message,search_forumid) AGAINST ('+fid272573 +(SmartLauncher)' IN BOOLEAN MODE )  order by messageid desc  limit 0,11
thd->thread_id=170
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

Number of processes running now: 0
[10 Mar 2004 16:25] Steven Roussey
Cleaner version of the stack trace (why the join stuff for non-join? FTS related?):

Stack range sanity check OK, backtrace follows:
0x814e4f3 handle_segfault + 455
0x400437ce _end + 934889310
0x818ede3 st_join_table::cleanup() + 15
0x818ef9a JOIN::join_free(bool) + 224
0x818971d JOIN::cleanup() + 235
0x8189a97 _Z12mysql_selectP3THDPPP4ItemP13st_table_listjR4ListIS1_ES2_jP8st_orderSB_S2_SB_mP13select_resultP18st_select_lex_unitP13st_sel + 663
0x818605b handle_select(THD*, st_lex*, select_result*) + 247
0x8163420 mysql_execute_command(THD*) + 4520
0x8167703 mysql_parse(THD*, char*, unsigned) + 247
0x816142f dispatch_command(enum_server_command, THD*, char*, unsigned) + 1673
0x8160d9b do_command(THD*) + 515
0x81602dc handle_one_connection + 626
0x4003e881 _end + 934869009
0x420e40c7 _end + 969101399
[10 Mar 2004 16:26] Steven Roussey
updated info
[11 Mar 2004 14:51] Steven Roussey
This only crashes when the index is the type from 4.0. When recreating the FTS index, this crash seems to disappear.
[14 Mar 2004 4:00] Alexander Keremidarski
Are these same tables for which yoiu have filled bug report #3142?
If yes both bugs can be closed as Full text indexes are known to be incompatible between 4.0 and 4.1 and have to be recreated.
[15 Mar 2004 15:38] Steven Roussey
Bug 3142 was using 4.1 index types. This was for 4.0. 4.1 should be able to read or write to either format (which it does, by the way). If it is not supported than it should warn/error/mark as crashed.
[16 Mar 2004 10:53] Sergei Golubchik
is there any way I could repeat it ?
[13 Sep 2004 19:26] Sergei Golubchik
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.