Seite 1 von 1

Crash des Mysql Servers

Verfasst: 15. Jul 2007 23:06
von TimN
Hi, ein Bekannter kümmert sich ehrenamtlich um ein online game. Jetzt stützt seit heute mittag regelmäßig der mysql server ab. Ich dachte ich poste mal das error log und hoffe es kann einer helfen.
Es läuft Suse Linux, Mysql Server Version 4.0.15 und ein update würde wohl mehr probleme bereiten. Bis gestern lief alles stabil.

Number of processes running now: 0
070715 14:35:29 mysqld restarted
/usr/sbin/mysqld: ready for connections.
Version: '4.0.15' socket: '/var/lib/mysql/mysql.sock' port: 3306
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=16777216
read_buffer_size=131072
max_used_connections=14
max_connections=100
threads_connected=6
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 80383 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x4160bf10
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=0x414379b8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81055b2
0x4008796c
0x400862c0
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 (nil) is invalid pointer
thd->thread_id=1155
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: 1
070715 14:38:17 mysqld restarted
/usr/sbin/mysqld: ready for connections.
Version: '4.0.15' socket: '/var/lib/mysql/mysql.sock' port: 3306
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=16777216
read_buffer_size=131072
max_used_connections=10
max_connections=100
threads_connected=3
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 80383 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x41400490
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=0x413415e8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81055b2
0x4008796c
0x400862d1
0x4008316f
0x4022c12c
0x81e8cbe
0x81e930b
0x80e4c71
0x816c3fa
0x816c19c
0x8168919
0x814a06e
0x8118a3b
0x81196e4
0x8114b7b
0x8113dc7
0x811362a
0x40081f60
0x40294327
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 0x82f3200 = update konstanten SET value='59' WHERE variable = 'windy'
thd->thread_id=893
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.
070715 18:33:30 mysqld started
/usr/sbin/mysqld: ready for connections.
Version: '4.0.15' socket: '/var/lib/mysql/mysql.sock' port: 3306
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=16777216
read_buffer_size=131072
max_used_connections=5
max_connections=100
threads_connected=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 80383 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x830ba70
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=0x4152f6b8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81055b2
0x4008796c
0x400862d1
0x4008316f
0x4022c12c
0x4016369e
0x816c129
0x8168919
Stack trace seems successful - bottom reached
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 0x8306780 = UPDATE provinzen SET kihandel='0' WHERE id = '112'
thd->thread_id=1254
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.
070715 19:00:15 mysqld started
/usr/sbin/mysqld: ready for connections.
Version: '4.0.15' socket: '/var/lib/mysql/mysql.sock' port: 3306
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=16777216
read_buffer_size=131072
max_used_connections=6
max_connections=100
threads_connected=5
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 80383 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8307b88
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=0x414986b8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81055b2
0x4008796c
0x400862d1
0x4008316f
0x4022c12c
0x4016369e
0x816c129
0x8168919
0x814a06e
0x8118a3b
0x81196e4
0x8114b7b
0x8113dc7
0x811362a
0x40081f60
0x40294327
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 0x8371850 = UPDATE provinzen SET kihandel='0' WHERE id = '342'
thd->thread_id=1094
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.
070715 19:26:41 mysqld started
/usr/sbin/mysqld: ready for connections.
Version: '4.0.15' socket: '/var/lib/mysql/mysql.sock' port: 3306
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=16777216
read_buffer_size=131072
max_used_connections=5
max_connections=100
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 80383 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x41400490
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=0x413a3e28, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81055b2
0x4008796c
0x81c5733
New value of fp=0x82855b8 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 0x82be6f0 = SELECT state, id FROM diplomatie WHERE user1 = 'kein Besitzer' AND user2 = 'Raptor'
thd->thread_id=1166
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: 1
070715 19:46:20 mysqld restarted
/usr/sbin/mysqld: ready for connections.
Version: '4.0.15' socket: '/var/lib/mysql/mysql.sock' port: 3306
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=16777216
read_buffer_size=131072
max_used_connections=3
max_connections=100
threads_connected=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 80383 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x82f2290
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=0x413d5a08, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81055b2
0x4008796c
0x400862c3
New value of fp=0x402e8a20 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 (nil) is invalid pointer
thd->thread_id=143
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.
070715 19:49:05 /usr/sbin/mysqld: Normal shutdown

070715 19:50:58 mysqld ended

070715 19:51:10 mysqld started
/usr/sbin/mysqld: ready for connections.
Version: '4.0.15' socket: '/var/lib/mysql/mysql.sock' port: 3306
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=16777216
read_buffer_size=131072
max_used_connections=5
max_connections=100
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 80383 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x833b0f8
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=0x413a3ec8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81055b2
0x4008796c
0x400862d1
0x4008316f
0x4022c26d
0x81e8d91
0x80ffd80
0x80f93c2
0x813dd1a
0x8134bfc
0x813312d
0x8118259
0x81196e4
0x8114b7b
0x8113dc7
0x811362a
0x40081f60
0x40294327
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 0x82b42b8 = SELECT state, id FROM diplomatie WHERE user1 = 'kein Besitzer' AND user2 = 'Caesar'
thd->thread_id=965
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.
070715 20:00:08 /usr/sbin/mysqld: Normal shutdown

070715 20:00:22 mysqld ended

070715 20:00:28 mysqld started
/usr/sbin/mysqld: ready for connections.
Version: '4.0.15' socket: '/var/lib/mysql/mysql.sock' port: 3306
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=16777216
read_buffer_size=131072
max_used_connections=8
max_connections=100
threads_connected=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 80383 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x82d8838
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=0x414682a8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81055b2
0x4008796c
0x400862d1
0x4008316f
0x4022c26d
0x81e8d91
0x81e9410
0x8167b2e
0x81677ed
0x814a539
0x8118a3b
0x81196e4
0x8114b7b
0x8113dc7
0x811362a
0x40081f60
0x40294327
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 0x831f720 = update konstanten SET value='69' WHERE variable = 'windx'
thd->thread_id=7552
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.
070715 21:42:41 /usr/sbin/mysqld: Normal shutdown

070715 21:42:54 mysqld ended

070715 21:43:01 mysqld started
/usr/sbin/mysqld: ready for connections.
Version: '4.0.15' socket: '/var/lib/mysql/mysql.sock' port: 3306
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=16777216
read_buffer_size=131072
max_used_connections=8
max_connections=100
threads_connected=3
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 80383 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x82d90c8
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=0x413a3ec8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81055b2
0x4008796c
0x400862d1
0x4008316f
0x4022c26d
0x81e8d91
0x80ffd80
0x80f93c2
0x813dd1a
0x8134bfc
0x813312d
0x8118259
0x81196e4
0x8114b7b
0x8113dc7
0x811362a
0x40081f60
0x40294327
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 0x831c948 = select * from konstanten
thd->thread_id=2105
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.
070715 22:01:20 /usr/sbin/mysqld: Normal shutdown

070715 22:01:32 mysqld ended

070715 22:01:43 mysqld started
/usr/sbin/mysqld: ready for connections.
Version: '4.0.15' socket: '/var/lib/mysql/mysql.sock' port: 3306

Für mehr Infos bitte posten, ich frage dann nach.

Danke schon mal Tim

Verfasst: 15. Jul 2007 23:37
von kahler
Eventuell irgendwelche Updates eingespielt, auch von irgendwelchen Bibliotheken. Klingt zumindest, als ob mySQL gegen eine andere als die installierte Bibliothek gelinkt ist.

Verfasst: 16. Jul 2007 14:59
von foo
MySQL mit Debug bauen, damit der Backtrace Symbolnamen hat. Noetigenfalls in GDB oder Valgrind starten, das sollte dann genug Info sein, um das auf der MySQL-Liste zu posten.

Vorher wuerde ich aber mal gucken, ob die Platte nicht vielleicht defekt ist (dmesg) ...

Verfasst: 16. Jul 2007 16:24
von tiwoc
foo hat geschrieben:Vorher wuerde ich aber mal gucken, ob die Platte nicht vielleicht defekt ist (dmesg) ...
smartctl aus den smartmontools leistet hier auch gute Dienste. Auch ein fsck mag helfen.

Verfasst: 16. Jul 2007 18:58
von TimN
Danke Euch schon mal für die schnelle Hilfe, das mit der defekten Hardware habe ich Ihm auch gesagt, er meinte er würde mal schauen.
Bis jetzt läuft wieder alles stabil und zwar ohne das etwas gemacht wurde. Klingt nach Datenmüll im Speicher evtl?
Und falls es wieder auftritt soll er es mal debug etc. probieren.

Danke nochmal gruß tim