Hi, our server crashed yesterday with the following error :
do_ypcall: clnt_call: RPC: Unable to receive; errno = Connection refused do_ypcall: clnt_call: RPC: Unable to receive; errno = Connection refused do_ypcall: clnt_call: RPC: Unable to receive; errno = Connection refused 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=8388608 read_buffer_size=520192 max_used_connections=392 max_connections=1000 threads_connected=8 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1540184 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x6bc2f258 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=0x45d4f88, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80f7893 0xc5ed96 0x82ab930 0x8158a17 0x82302c1 0x819f373 0x815d4e2 0x8105657 0x810868d 0x8103321 0x8102eb8 0x810280d 0xc59e51 0x50e06a 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 0x6c0095e8 is invalid pointer thd->thread_id=109709885 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. 060706 1:26:24 InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 165 358046223 InnoDB: Doing recovery: scanned up to log sequence number 165 363289088 InnoDB: Doing recovery: scanned up to log sequence number 165 368531968 InnoDB: Doing recovery: scanned up to log sequence number 165 373774848 InnoDB: Doing recovery: scanned up to log sequence number 165 374990041 060706 1:26:24 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed 060706 1:26:28 InnoDB: Flushing modified pages from the buffer pool... 060706 1:26:28 InnoDB: Started /var/lib/mysql/MySQL4.0.18/libexec/mysqld: ready for connections. Version: '4.0.18' socket: '/var/lib/mysql/MySQL4.0.18/var/mysql4.0.18.sock' port: 3306 resolved stack gives : 0x80f7893 handle_segfault + 399 0xc5ed96 (?) 0x82ab930 strnmov + 24 0x8158a17 innobase_mysql_print_thd + 471 0x82302c1 lock_print_info + 1573 0x819f373 srv_sprintf_innodb_monitor + 507 0x815d4e2 _Z18innodb_show_statusP3THD + 138 0x8105657 _Z21mysql_execute_commandv + 5999 0x810868d _Z11mysql_parseP3THDPcj + 329 0x8103321 _Z16dispatch_command19enum_server_commandP3THDPcj + 1069 0x8102eb8 _Z10do_commandP3THD + 100 0x810280d handle_one_connection + 841 0xc59e51 (?) 0x50e06a (?) this is a Mysql 4.0.18 on a dedicated linux Red Hat Enterprise Linux ES release 3 ( kernel 2.4.21-20 ) with 3 Gig RAM could you tell me what happened please? -- Dilipan Sebastiampillai Systems - DBA -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
