Michael, the crashes below happen in independent areas of code. The 2 first are inside InnoDB, and the third inside MySQL. This looks like random thread crashes, or random memory corruption.
I assume that you have my.cnf set so that the memory usage cannot approach 2 GB. You are running a relatively new Linux kernel, 2.4.23. Did the crashes start when you upgraded Linux? Best regards, Heikki Innobase Oy http://www.innodb.com InnoDB - transactions, row level locking, and foreign keys for MySQL InnoDB Hot Backup - a hot backup tool for InnoDB which also backs up MyISAM tables Order MySQL support from http://www.mysql.com/support/index.html ..................... List:MySQL General Discussion« Previous MessageNext Message » From:Michael BacarellaDate:January 16 2004 12:32am Subject:MySQL 3.23.58 seg faults occasionally First we cut to the chase with a resolved stack trace from the most recent crash: 0x80c23d5 handle_segfault__Fi + 425 0x40022f54 _end + 935506260 0x822cdef btr_search_build_page_hash_index + 4771 0x82281c3 btr_search_info_update_slow + 919 0x8213f9e btr_cur_search_to_nth_level + 3154 0x81e9dce row_sel_get_clust_rec_for_mysql + 102 0x81ece61 row_search_for_mysql + 6769 0x8111152 general_fetch__11ha_innobasePcUiUi + 322 0x8111220 index_next_same__11ha_innobasePcPCcUi + 40 0x80e7d7d join_read_next__FP14st_read_record + 53 0x80e74d9 sub_select__FP4JOINP13st_join_tableb + 341 0x80e7190 do_select__FP4JOINPt4List1Z4ItemP8st_tableP9Procedure + 412 0x80dff58 mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8st_orderT4T3T4UiP1 3select_result + 5576 0x80c8aba mysql_execute_command__Fv + 806 0x80cbd88 mysql_parse__FP3THDPcUi + 72 0x80c7c74 do_command__FP3THD + 1324 0x80c7127 handle_one_connection__FPv + 659 and the one before it: 0x80c23d5 handle_segfault__Fi + 425 0x40022f54 _end + 935506260 0x823d4a8 trx_rseg_get_on_id + 24 0x823952d trx_undo_get_undo_rec_low + 45 0x823977d trx_undo_get_undo_rec + 49 0x82399c0 trx_undo_prev_version_build + 548 0x81f3f35 row_vers_build_for_consistent_read + 641 0x81e9d5e row_sel_build_prev_vers_for_mysql + 226 0x81ecda4 row_search_for_mysql + 6580 0x8111152 general_fetch__11ha_innobasePcUiUi + 322 0x8111373 rnd_next__11ha_innobasePc + 83 0x8103da6 rr_sequential__FP14st_read_record + 150 0x80e74d9 sub_select__FP4JOINP13st_join_tableb + 341 0x80e7190 do_select__FP4JOINPt4List1Z4ItemP8st_tableP9Procedure + 412 0x80dff58 mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8st_orderT4T3T4UiP1 3select_result + 5576 0x80c8aba mysql_execute_command__Fv + 806 0x80cbd88 mysql_parse__FP3THDPcUi + 72 0x80c7c74 do_command__FP3THD + 1324 0x80c7127 handle_one_connection__FPv + 659 and the one before that: 0x80c23d5 handle_segfault__Fi + 425 0x40022f54 _end + 935506260 0x401141b7 _end + 936494007 0x80f42f7 write_header__9Log_eventP11st_io_cache + 91 0x80f426c write__9Log_eventP11st_io_cache + 24 0x80f424d write__15Query_log_eventP11st_io_cache + 37 0x80f3333 write__9MYSQL_LOGP15Query_log_event + 1507 0x80eceec mysql_insert__FP3THDP13st_table_listRt4List1Z4ItemRt4List1Zt4List1Z4Item15en um_duplicates13thr_lock_type + 1752 0x80c9dd0 mysql_execute_command__Fv + 5692 0x80cbd88 mysql_parse__FP3THDPcUi + 72 0x80c7c74 do_command__FP3THD + 1324 0x80c7127 handle_one_connection__FPv + 659 Typically this happens to me on a heavily loaded server where I'm querying against a not very memory resident table so it takes a few seconds to load. Afterwards, when the table is better cached I issue a few more queries and one of them eventually causes the seg fault. It doesn't really crash on itself during normal load, only if I go in and introduce non-typical queries. All tables are InnoDB. Data and log files are stored on independent Linux MD based RAID-1 arrays. Data is stored on a raw array, logs are stored on an ext3fs. Host OS is Debian "stable" branch. The machine survived 18 days of CTCS burn-in before we turned MySQL loose. *** mysqlbug output: Server version 3.23.58-max-log Protocol version 10 Connection Localhost via UNIX socket UNIX socket /tmp/mysql.sock Uptime: 11 min 12 sec Threads: 10 Questions: 652813 Slow queries: 301 Opens: 39775 Flush tables: 1 Open tables: 256 Queries per second avg: 971.448 System: Linux dbms3 2.4.23 #1 SMP Tue Dec 23 03:08:01 EST 2003 i686 unknown Architecture: i686 Some paths: /usr/bin/perl /usr/bin/make /usr/bin/gcc /usr/bin/cc GCC: Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20011002 (Debian prerelease) Compilation info: CC='gcc' CFLAGS='-O2 -mpentiumpro' CXX='gcc' CXXFLAGS='-O2 -mpentiumpro -felide-constructors' LDFLAGS='' LIBC: lrwxrwxrwx 1 root root 13 Dec 23 10:41 /lib/libc.so.6 -> libc-2.2.5.so -rwxr-xr-x 1 root root 1153784 Apr 8 2003 /lib/libc-2.2.5.so -rw-r--r-- 1 root root 2391002 Apr 8 2003 /usr/lib/libc.a -rw-r--r-- 1 root root 178 Apr 8 2003 /usr/lib/libc.so Configure command: ./configure '--prefix=/usr/local/mysql' '--with-comment=Official MySQL-max binary' '--with-extra-charsets=complex' '-- with-server-suffix=-max' '--enable-thread-safe-client' '--enable-local-infile' '--enable-assembler' '--disable-shared' '--with-berkeley-d b' '--with-innodb' 'CFLAGS=-O2 -mpentiumpro' 'CXXFLAGS=-O2 -mpentiumpro -felide-constructors' 'CXX=gcc' *** server error log mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary [...] and this may fail key_buffer_size=134213632 record_buffer=131072 sort_buffer=4194296 max_used_connections=415 max_connections=415 threads_connected=19 It is possible that mysqld could use up to key_buffer_size + (record_buffer + sort_buffer)*max_connections = 1884024 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: 0x80c23d5 0x40022f54 0x822cdef 0x82281c3 0x8213f9e 0x81eb12e 0x81ebe8a 0x8110e36 0x80e7c37 0x80e73d6 0x80e7586 0x80e7586 0x80e7586 0x80e7486 0x80e7486 0x80e7486 0x80e7486 0x80e7190 0x80df9d7 0x80c8aba 0x80cbd88 0x80c7c74 0x80c7127 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 0x7ac20850 is invalid pointer thd->thread_id=3144355 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 3144355 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 040115 12:16:54 mysqld restarted -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
