| 12
 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
 
 | Feb  9 16:23:39 ns2095884 mysqld[6766]: 100209 16:23:39 - mysqld got signal 11;
Feb  9 16:23:39 ns2095884 mysqld[6766]: This could be because you hit a bug. It is also possible that this binary
Feb  9 16:23:39 ns2095884 mysqld[6766]: or one of the libraries it was linked against is corrupt, improperly built,
Feb  9 16:23:39 ns2095884 mysqld[6766]: or misconfigured. This error can also be caused by malfunctioning hardware.
Feb  9 16:23:39 ns2095884 mysqld[6766]: We will try our best to scrape up some info that will hopefully help diagnose
Feb  9 16:23:39 ns2095884 mysqld[6766]: the problem, but since we have already crashed, something is definitely wrong
Feb  9 16:23:39 ns2095884 mysqld[6766]: and this may fail.
Feb  9 16:23:39 ns2095884 mysqld[6766]: 
Feb  9 16:23:39 ns2095884 mysqld[6766]: key_buffer_size=83886080
Feb  9 16:23:39 ns2095884 mysqld[6766]: read_buffer_size=131072
Feb  9 16:23:39 ns2095884 mysqld[6766]: max_used_connections=203
Feb  9 16:23:39 ns2095884 mysqld[6766]: max_connections=300
Feb  9 16:23:39 ns2095884 mysqld[6766]: threads_connected=56
Feb  9 16:23:39 ns2095884 mysqld[6766]: It is possible that mysqld could use up to 
Feb  9 16:23:39 ns2095884 mysqld[6766]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 734717 K
Feb  9 16:23:39 ns2095884 mysqld[6766]: bytes of memory
Feb  9 16:23:39 ns2095884 mysqld[6766]: Hope that's ok; if not, decrease some variables in the equation.
Feb  9 16:23:39 ns2095884 mysqld[6766]: 
Feb  9 16:23:39 ns2095884 mysqld[6766]: thd=0x7ff6940d5f30
Feb  9 16:23:39 ns2095884 mysqld[6766]: Attempting backtrace. You can use the following information to find out
Feb  9 16:23:39 ns2095884 mysqld[6766]: where mysqld died. If you see no messages after this, something went
Feb  9 16:23:39 ns2095884 mysqld[6766]: terribly wrong...
Feb  9 16:23:39 ns2095884 mysqld[6766]: Cannot determine thread, fp=0x7ff6940d5f30, backtrace may not be correct.
Feb  9 16:23:39 ns2095884 mysqld[6766]: Bogus stack limit or frame pointer, fp=0x7ff6940d5f30, stack_bottom=0x415d0000, thread_stack=131072, aborting backtrace.
Feb  9 16:23:39 ns2095884 mysqld[6766]: Trying to get some variables.
Feb  9 16:23:39 ns2095884 mysqld[6766]: Some pointers may be invalid and cause the dump to abort...
Feb  9 16:23:39 ns2095884 mysqld[6766]: thd->query at 0x2b14f80 = SELECT ............... LIMIT 10
Feb  9 16:23:39 ns2095884 mysqld[6766]: thd->thread_id=42105
Feb  9 16:23:39 ns2095884 mysqld[6766]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Feb  9 16:23:39 ns2095884 mysqld[6766]: information that should help you find out what is causing the crash.
Feb  9 16:23:39 ns2095884 kernel: grsec: Segmentation fault occurred at (null) in /usr/sbin/mysqld[mysqld:2168] uid/euid:103/103 gid/egid:107/107, parent /usr/bin/mysqld_safe[mysqld_safe:3717] uid/euid:0/0 gid/egid:0/0
Feb  9 16:24:01 ns2095884 /USR/SBIN/CRON[2181]: (root) CMD (/usr/local/rtm/bin/rtm 55 > /dev/null 2> /dev/null) | 
Partager