| Bug #20133 | mysql 5.0.15-log restart | ||
|---|---|---|---|
| Submitted: | 30 May 2006 2:21 | Modified: | 30 Jun 2006 5:23 |
| Reporter: | wang yue | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | MySQL Server | Severity: | S1 (Critical) |
| Version: | 5.0.15-log | OS: | Linux (linux 2.6) |
| Assigned to: | CPU Architecture: | Any | |
[30 May 2006 2:21]
wang yue
[30 May 2006 5:01]
Valeriy Kravchuk
Thank you for a problem report. Please, upload part of the error log with information about the crash. And, surely, upgrade to 5.0.21 and try to repeat the crash with this version. 5.0.15 is really old.
[30 May 2006 5:13]
wang yue
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=268435456 read_buffer_size=2093056 max_used_connections=12 max_connections=100 threads_connected=4 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 671343 K 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=268435456 read_buffer_size=2093056 max_used_connections=12 max_connections=100 threads_connected=4 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 671343 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x886e180 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=0x67a87db8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x814caec 0x4002647e 0x82ff808 0x82a01a0 0x82a0c18 0x829f1f7 0x8294740 0x8279847 0x82755ea 0x81ef6f3 0x819ebb9 0x8190def 0x8196c94 0x8190d9e 0x8196956 0x818d73d 0x818e245 0x818a5f2 0x8160209 0x8166ce2 0x815eb02 0x815e635 0x815db00 0x40020941 0x420da1ca 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 Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x67d1ed38 is invalid pointer thd->thread_id=20550 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 060530 02:13:42 mysqld restarted 060530 2:13:42 [Warning] Changed limits: max_open_files: 1024 max_connections: 100 table_cache: 457 060530 2:13:42 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hos tname changed!! Please use '--log-bin=tc-wiki-db00-bin' to avoid this problem.
[30 May 2006 5:23]
Valeriy Kravchuk
Can you, please, check you general query log for the SQL statement that caused this crash? We have to identify it. What about upgrade to 5.0.21?
[30 Jun 2006 23:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
