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: | |
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
[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.