Richard, > thd->query at 0x89af670 = SELECT * FROM order_data WHERE viewed='' ORDER > BY order_num DESC
what does SHOW CREATE TABLE order_data; say? What does CHECK TABLE order_data; say? Does it print anything to the .err log in the MySQL datadir? Please resolve the stack trace below: > Stack range sanity check OK, backtrace follows: > 0x80dbe1f > 0x4003b47e > 0x8101e09 > 0x810e90d > 0x80e6d8a > 0x80ea88b > 0x80e5ed3 > 0x80ebe0e > 0x80e50bf > 0x40035941 > 0x420da1ca > 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. Best regards, Heikki Tuuri Innobase Oy http://www.innodb.com Transactions, foreign keys, and a hot backup tool for MySQL Order MySQL technical support from https://order.mysql.com/ ----- Original Message ----- From: "Richard Gabriel" <[EMAIL PROTECTED]> Newsgroups: mailing.database.mysql Sent: Friday, August 08, 2003 11:50 PM Subject: read_const error 127 - then MySQL dies > Hi all, > > The following keeps happening and I can't pinpoint a query that is > causing it. It did not happen in 3.23.x, but started upon upgrading to > 4.0.14. The operating system/hardware information is as follows: > > RedHat 8.0 - kernel 2.4.18SMP > 4x Xeon Processors > 4x 80GB SCSI drives (hardware RAID-10) > 2GB RAM > > The following is a log exerpt: > > 030808 15:22:09 read_const: Got error 127 when reading table **** > 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 > read_buffer_size=131072 > max_used_connections=184 > max_connections=1000 > threads_connected=21 > It is possible that mysqld could use up to > key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections > = 2184184 K > bytes of memory > Hope that's ok; if not, decrease some variables in the equation. > > thd=0x98772088 > 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=0x98a4ad98, backtrace may not be correct. > Stack range sanity check OK, backtrace follows: > 0x80dbe1f > 0x4003b47e > 0x8101e09 > 0x810e90d > 0x80e6d8a > 0x80ea88b > 0x80e5ed3 > 0x80ebe0e > 0x80e50bf > 0x40035941 > 0x420da1ca > 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 0x89af670 = SELECT * FROM order_data WHERE viewed='' ORDER > BY order_num DESC > thd->thread_id=42660972 > 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 > 030808 15:22:19 mysqld restarted > 030808 15:22:20 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 5 4012008225 > InnoDB: Doing recovery: scanned up to log sequence number 5 4012079335 > 030808 15:22:20 InnoDB: Starting an apply batch of log records to the > database... > InnoDB: Progress in percents: 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 > InnoDB: Apply batch completed > InnoDB: Last MySQL binlog file position 0 1058709429, file name > ./db1-bin.062 > 030808 15:22:21 InnoDB: Flushing modified pages from the buffer pool... > 030808 15:22:21 InnoDB: Started > /usr/sbin/mysqld-max: ready for connections. > Version: '4.0.14-Max-log' socket: '/var/lib/mysql/mysql.sock' port: > 3306 > > > This happens often. Any ideas? Thanks. > > -- > Richard Gabriel <[EMAIL PROTECTED]> > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
