RootForum Community

Code: Select all

030415 19:32:17  mysqld restarted
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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...
Stack range sanity check OK, backtrace follows:
0x40085e9d
0x4020f950
0x8149f9e
0x80f3f2e
0x80da171
0x80d0879
0x80b6700
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x823e060 = SELECT g.group_id, g.group_name 
        FROM phpbb_auth_access aa, phpbb_user_group ug, phpbb_groups g 
        WHERE aa.forum_id = 2
                AND aa.auth_mod = 1 
                AND g.group_single_user = 0
                AND g.group_type <> 2
                AND ug.group_id = aa.group_id 
                AND g.group_id = aa.group_id 
        GROUP BY g.group_id, g.group_name  
        ORDER BY g.group_id
thd->thread_id = 19
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 19 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030415 19:34:33  mysqld restarted
/usr/sbin/mysqld: ready for connections
030415 19:35:28  /usr/sbin/mysqld: Normal shutdown

030415 19:35:28  /usr/sbin/mysqld: Shutdown Complete

030415 19:35:28  mysqld ended

030415 19:35:29  mysqld started
/usr/sbin/mysqld: ready for connections
030415 19:41:45  /usr/sbin/mysqld: Normal shutdown

030415 19:41:45  /usr/sbin/mysqld: Shutdown Complete

030415 19:41:45  mysqld ended

030415 19:41:46  mysqld started
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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...
Stack range sanity check OK, backtrace follows:
0x40085e9d
0x4020f950
0x8149f9e
0x814a58a
0x80ee688
0x80d0a13
0x80d1469
0x80cf81d
0x80b6700
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x82531a8 = SELECT aa.forum_id, u.user_id, u.username 
                FROM phpbb_auth_access aa, phpbb_user_group ug, phpbb_groups g, phpbb_users u
                WHERE aa.auth_mod = 1 
                        AND g.group_single_user = 1 
                        AND ug.group_id = aa.group_id 
                        AND g.group_id = aa.group_id 
                        AND u.user_id = ug.user_id 
                GROUP BY u.user_id, u.username, aa.forum_id 
                ORDER BY aa.forum_id, u.user_id
thd->thread_id = 7315
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 7315 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030418 01:54:30  mysqld restarted
/usr/sbin/mysqld: ready for connections
030418 12:30:19  /usr/sbin/mysqld: Normal shutdown

030418 12:30:19  /usr/sbin/mysqld: Shutdown Complete

030418 12:30:19  mysqld ended

030418 12:30:39  mysqld started
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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...
Stack range sanity check OK, backtrace follows:
0x40085e9d
0x80ac250
0x80ac4ac
0x80c8832
0x80a9b5d
0x80d7cb3
0x80d08ac
0x80b6700
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8291140 = SELECT u.*, s.*
                        FROM phpbb_sessions s, phpbb_users u
                        WHERE s.session_id = 'c284869a1d4a3eb6140136ed880861d5'
                                AND u.user_id = s.session_user_id
thd->thread_id = 23599
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 23599 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030425 18:49:42  mysqld restarted
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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, ebp=0xbfffefb4, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x40085e9d
0x4020f950
0x8149f9e
0x80aba9b
0x80b1738
0x80b0ebb
0x40116c5f
0x8089af1
New value of ebp failed sanity check, terminating backtrace!

Number of processes running now: 0
030425 20:48:00  mysqld restarted
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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...
Stack range sanity check OK, backtrace follows:
0x40085e9d
0x4020f950
0x8149f9e
0x814a58a
0x809d782
0x80f21d2
0x80f1cfd
0x80eea6a
0x80e0b3d
0x80b7833
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x821f4d8 = UPDATE phpbb_users 
                                                        SET user_session_time = 1051310711, user_session_page = 11 
                                                        WHERE user_id = 17
thd->thread_id = 538
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 538 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030426 00:45:11  mysqld restarted
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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...
Stack range sanity check OK, backtrace follows:
0x40085e9d
0x4020f950
0x8149f9e
0x814a58a
0x809d782
0x80f21d2
0x80f1cfd
0x80eea6a
0x80e0b3d
0x80b7833
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8230ee0 = UPDATE phpbb_users 
                                                        SET user_session_time = 1051311950, user_session_page = 11 
                                                        WHERE user_id = 9
thd->thread_id = 55
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 55 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030426 01:05:50  mysqld restarted
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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...
Stack range sanity check OK, backtrace follows:
0x40085e9d
0x80ac250
0x80ac4ac
0x80c8832
0x80a9b5d
0x80d7cb3
0x80d08ac
0x80b6700
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x823c4e8 = SELECT u.*, s.*
                        FROM phpbb_sessions s, phpbb_users u
                        WHERE s.session_id = '9c8f63d2b1e16f5db56db00bc8922af1'
                                AND u.user_id = s.session_user_id
thd->thread_id = 106
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 106 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030426 01:40:48  mysqld restarted
/usr/sbin/mysqld: ready for connections
030426 21:03:46  Aborted connection 2854 to db: 'usr_web17_1' user: 'web17' host: `localhost' (Got an error reading communication packets)
030427 17:37:08  /usr/sbin/mysqld: Normal shutdown

030427 17:37:08  /usr/sbin/mysqld: Shutdown Complete

030427 17:37:08  mysqld ended

030427 17:37:08  mysqld started
/usr/sbin/mysqld: ready for connections
030428 16:45:24  Aborted connection 4460 to db: 'confixx' user: 'confixx' host: `localhost' (Got an error reading communication packets)
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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...
Stack range sanity check OK, backtrace follows:
0x40085e9d
0x80ac250
0x80ac4ac
0x80c8832
0x80a9b5d
0x80d7cb3
0x80d08ac
0x80b6700
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x822c348 = SELECT u.*, s.*
                        FROM phpbb_sessions s, phpbb_users u
                        WHERE s.session_id = 'b380ab9daf2dce223816edd0a5b1a87c'
                                AND u.user_id = s.session_user_id
thd->thread_id = 8597
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 8597 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030429 15:10:24  mysqld restarted
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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...
Stack range sanity check OK, backtrace follows:
0x40085e9d
0x4020f950
0x400b9609
0x400b97f0
0x80d6628
0x80cff22
0x80b6700
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x82901c8 = SELECT c.cat_id, c.cat_title, c.cat_order
                FROM phpbb_categories c, phpbb_forums f
                WHERE f.cat_id = c.cat_id
                GROUP BY c.cat_id, c.cat_title, c.cat_order
                ORDER BY c.cat_order
thd->thread_id = 290
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 290 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030429 16:31:30  mysqld restarted
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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...
Stack range sanity check OK, backtrace follows:
0x40085e9d
0x4020f950
0x8149f9e
0x814a58a
0x809d782
0x80f21d2
0x80f1cfd
0x80eea6a
0x80d0a13
0x80d1469
0x80cf81d
0x80b6700
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8253f58 = SELECT u.user_id, u.username 
        FROM phpbb_auth_access aa, phpbb_user_group ug, phpbb_groups g, phpbb_users u
        WHERE aa.forum_id = 2 
                AND aa.auth_mod = 1 
                AND g.group_single_user = 1
                AND ug.group_id = aa.group_id 
                AND g.group_id = aa.group_id 
                AND u.user_id = ug.user_id 
        GROUP BY u.user_id, u.username  
        ORDER BY u.user_id
thd->thread_id = 30
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 30 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030429 16:34:12  mysqld restarted
/usr/sbin/mysqld: ready for connections
030429 16:34:23  /usr/sbin/mysqld: Normal shutdown

030429 16:34:23  /usr/sbin/mysqld: Shutdown Complete

030429 16:34:23  mysqld ended

030429 16:34:37  mysqld started
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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...
Stack range sanity check OK, backtrace follows:
0x40085e9d
0x4020f950
0x8149f9e
0x814a58a
0x809d782
0x80f21d2
0x80f1cfd
0x80eea6a
0x80d0a13
0x80d1469
0x80cf81d
0x80b6700
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8236420 = SELECT a.forum_id, a.auth_view, a.auth_mod 
                        FROM phpbb_auth_access a, phpbb_user_group ug 
                        WHERE ug.user_id = 2 
                                AND ug.user_pending = 0 
                                AND a.group_id = ug.group_id

thd->thread_id = 18
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 18 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030429 16:36:35  mysqld restarted
/usr/sbin/mysqld: ready for connections
030429 18:00:20  Aborted connection 419 to db: 'usr_web20_1' user: 'web20' host: `localhost' (Got an error reading communication packets)
030429 18:37:40  Aborted connection 502 to db: 'usr_web17_1' user: 'web17' host: `localhost' (Got an error reading communication packets)
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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...
Stack range sanity check OK, backtrace follows:
0x40085e9d
0x80ac250
0x80ac4ac
0x80c8832
0x80a9b5d
0x80d7cb3
0x80d08ac
0x80b6700
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x82485e8 = SELECT u.*, s.*
                        FROM phpbb_sessions s, phpbb_users u
                        WHERE s.session_id = 'bfbfa07d257319a211f0796e1dd1d06e'
                                AND u.user_id = s.session_user_id
thd->thread_id = 729
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 729 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030429 19:50:14  mysqld restarted
/usr/sbin/mysqld: ready for connections

Code: Select all

# Example mysql config file for medium systems.
#
# This is for a system with little memory (32M - 64M) where MySQL plays
# a important part and systems up to 128M very MySQL is used together with
# other programs (like a web server)
#
# You can copy this file to
# /etc/mf.cnf to set global options,
# mysql-data-dir/my.cnf to set server-specific options (in this
# installation this directory is /var/lib/mysql) or
# ~/.my.cnf to set user-specific options.
#
# One can in this file use all long options that the program supports.
# If you want to know which options a program support, run the program
# with --help option.

# The following options will be passed to all MySQL clients
[client]
#password       = your_password
port            = 3306
socket          = /var/lib/mysql/mysql.sock

# Here follows entries for some specific programs

# The MySQL server
[mysqld]
port            = 3306
socket          = /var/lib/mysql/mysql.sock
skip-locking
set-variable    = key_buffer=16M
set-variable    = max_allowed_packet=12M
set-variable    = table_cache=64
set-variable    = sort_buffer=512K
set-variable    = net_buffer_length=8K
set-variable    = myisam_sort_buffer_size=8M
log-bin
server-id       = 1
safe-show-database

# Point the following paths to different dedicated disks
#tmpdir         = /tmp/
#log-update     = /path-to-dedicated-directory/hostname

# Uncomment the following if you are using BDB tables
#set-variable   = bdb_cache_size=4M
#set-variable   = bdb_max_lock=10000

# Uncomment the following if you are using Innobase tables
#innodb_data_home_dir = /var/lib/mysql/
#innodb_log_group_home_dir = /var/lib/mysql/
#innodb_log_arch_dir = /var/lib/mysql/
#innodb_data_file_path = ibdata1:25M;ibdata2:37M;ibdata3:100M;ibdata4:300M
#set-variable = innodb_mirrored_log_groups=1
#set-variable = innodb_log_files_in_group=3
#set-variable = innodb_log_file_size=5M
#set-variable = innodb_log_buffer_size=8M
#innodb_flush_log_at_trx_commit=1
#innodb_log_archive=0
#set-variable = innodb_buffer_pool_size=16M
#set-variable = innodb_additional_mem_pool_size=2M
#set-variable = innodb_file_io_threads=4
#set-variable = innodb_lock_wait_timeout=50

[mysqldump]
quick
set-variable    = max_allowed_packet=12M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates


[isamchk]
set-variable    = key_buffer=20M
set-variable    = sort_buffer=20M
set-variable    = read_buffer=2M
set-variable    = write_buffer=2M

[myisamchk]
set-variable    = key_buffer=20M
set-variable    = sort_buffer=20M
set-variable    = read_buffer=2M
set-variable    = write_buffer=2M

[mysqlhotcopy]
interactive-timeout

[safe_mysqld]
err-log=/var/log/mysqld.log

Code: Select all

 myisamchk --silent --force */*.MYI
myisamchk: MyISAM file confixx/allgemein.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file confixx/register.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file confixx/zeiten.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web17_1/phpbb_forums.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web17_1/phpbb_posts.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web17_1/phpbb_posts_text.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web17_1/phpbb_sessions.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web17_1/phpbb_topics.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web17_1/phpbb_topics_watch.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web17_1/phpbb_users.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web20_1/phpbb_forums.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web20_1/phpbb_posts.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web20_1/phpbb_posts_text.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web20_1/phpbb_search_wordlist.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web20_1/phpbb_search_wordmatch.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: error: Key in wrong position at page 78848
myisamchk: MyISAM file usr_web20_1/phpbb_sessions.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web20_1/phpbb_topics.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web20_1/phpbb_users.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web20_1/phpbb_vote_results.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web20_1/phpbb_vote_voters.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly

Code: Select all

/usr/sbin/mysqld: ready for connections
mysqld got signal 4;
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=16773120
record_buffer=131072
sort_buffer=524280
max_used_connections=1
max_connections=100
threads_connected=1
It is possible that mysqld could use up to 
key_buffer_size + (record_buffer + sort_buffer)*max_connections = 80379 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...
Stack range sanity check OK, backtrace follows:
0x80a87c5
0x40031e9d
0xbf9ff350
0x80b221e
0x80ae0fa
0x80ad577
Stack trace seems successful - bottom reached
Please read http://www.mysql.com/doc/U/s/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 0x81f36a0 = SHOW TABLE STATUS LIKE 'phpbb_disallow'
thd->thread_id=526

Successfully dumped variables, if you ran with --log, take a look at the
details of what thread 526 did to cause the crash.  In some cases of really
bad corruption, the values shown above may be invalid

The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
information that should help you find out what is causing the crash

Number of processes running now: 0
030504 00:25:28  mysqld restarted
/usr/sbin/mysqld: ready for connections

Code: Select all

server1:~ # badblocks -v -s /dev/hda
Checking for bad blocks in read-only mode
From block 0 to 40209120
Checking for bad blocks (read-only test): 156128080/ 40209120
1561281
1561282
1561283
1561284
1561285
1561286
1561287
1561288
1561289
1561290
1561291
1561292
1561293
1561294
1561295
1561296
1561297
1561298
1561299
156130000/ 40209120
1561301
1561302
1561303
156130404/ 40209120
156130505/ 40209120
156130606/ 40209120
156130707/ 40209120