can u show us the innodb parameters in the my.cnf file.
On Sat, Jan 8, 2011 at 10:31 PM, Pito Salas <rps@stripped> wrote:
> I am very new to trying to solve a problem like this and have searched
> and searched the web for a useful troubleshooting guide but I am
> honestly stuck. I wonder if anyone out there could take a look at this
> bit of mysqld log. Any help at all would be greatly appreciated!!!
> 110107 15:07:15 mysqld started
> 110107 15:07:15 InnoDB: Database was not shut down normally!
> InnoDB: Starting crash recovery.
> InnoDB: Reading tablespace information from the .ibd files...
> InnoDB: Restoring possible half-written data pages from the doublewrite
> InnoDB: buffer...
> 110107 15:07:15 InnoDB: Starting log scan based on checkpoint at
> InnoDB: log sequence number 35 515914826.
> InnoDB: Doing recovery: scanned up to log sequence number 35 515915839
> InnoDB: 1 transaction(s) which must be rolled back or cleaned up
> InnoDB: in total 1 row operations to undo
> InnoDB: Trx id counter is 0 1697553664
> 110107 15:07:15 InnoDB: Starting an apply batch of log records to the
> InnoDB: Progress in percents: 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
> InnoDB: Apply batch completed
> InnoDB: Starting rollback of uncommitted transactions
> InnoDB: Rolling back trx with id 0 1697553198, 1 rows to undoInnoDB:
> Error: trying to
> access page number 3522914176 in space 0,
> InnoDB: space name ./ibdata1,
> InnoDB: which is outside the tablespace bounds.
> InnoDB: Byte offset 0, len 16384, i/o type 10
> 110107 15:07:15InnoDB: Assertion failure in thread 3086403264 in file
> fil0fil.c line
> InnoDB: We intentionally generate a memory trap.
> InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
> InnoDB: If you get repeated assertion failures or crashes, even
> InnoDB: immediately after the mysqld startup, there may be
> InnoDB: corruption in the InnoDB tablespace. Please refer to
> InnoDB: http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
> InnoDB: about forcing recovery.
> 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
> the problem, but since we have already crashed, something is definitely
> and this may fail.
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size +
> sort_buffer_size)*max_connections = 217599 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...
> Cannot determine thread, fp=0xbffc55ac, backtrace may not be correct.
> Stack range sanity check OK, backtrace follows:
> New value of fp=(nil) failed sanity check, terminating stack trace!
> Please read http://dev.mysql.com/doc/mysql/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 The manual page at http://www.mysql.com/doc/en/Crashing.htmlcontains
> information that should help you find out what is causing the crash.
> 110107 15:07:15 mysqld ended
> Check out http://www.salas.com and http://www.blogbridge.com/look
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql?unsub=1