Bug #17733 Flushing logs causes daily server crash
Submitted: 27 Feb 2006 1:37 Modified: 9 Dec 2006 18:35
Reporter: Steve Simitzis Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S1 (Critical)
Version:5.1-BK, 5.0-BK, 5.0.18, 5.0.19, 5.0.21 OS:Linux (Linux, Debian unstable, AMD64)
Assigned to: Kristofer Pettersson CPU Architecture:Any

[27 Feb 2006 1:37] Steve Simitzis
Description:
Every morning at 6:25am, mysqladmin flush-logs runs, and the server reliably crashes. This only started happening when I upgraded to 5.0.18 from 4.1.x.

I'm not sure if this matters or not, but this only happens on my replication server, not on my main database server which does not replicate.

How to repeat:
mysqladmin flush-logs
[27 Feb 2006 1:39] Steve Simitzis
Resolved stack trace:

0x818f37c handle_segfault + 668
0xffffe420 _end + -140762576
0x863bfc4 my_fast_mutexattr + 0
0x82019ac _ZN9MYSQL_LOG22purge_logs_before_dateEl + 92
0x8202b47 _ZN9MYSQL_LOG16rotate_and_purgeEj + 199
0x819f627 _Z20reload_acl_and_cacheP3THDmP13st_table_listPb + 471
0x81a9257 _Z16dispatch_command19enum_server_commandP3THDPcj + 2343
0x81a9fd8 _Z10do_commandP3THD + 136
0x81aa924 handle_one_connection + 2100
0xb7faeced _end + -1349047555
0xb7defdde _end + -1350878226
[27 Feb 2006 1:40] Steve Simitzis
my.cnf

Attachment: my.cnf (application/octet-stream, text), 4.15 KiB.

[27 Feb 2006 1:41] Steve Simitzis
Feb 26 06:25:45 db-slave mysqld[19074]: mysqld got signal 11;
Feb 26 06:25:45 db-slave mysqld[19074]: This could be because you hit a bug. It is also possible that this binary
Feb 26 06:25:45 db-slave mysqld[19074]: or one of the libraries it was linked against is corrupt, improperly built,
Feb 26 06:25:45 db-slave mysqld[19074]: or misconfigured. This error can also be caused by malfunctioning hardware.
Feb 26 06:25:45 db-slave mysqld[19074]: We will try our best to scrape up some info that will hopefully help diagnose
Feb 26 06:25:45 db-slave mysqld[19074]: the problem, but since we have already crashed, something is definitely wrong
Feb 26 06:25:45 db-slave mysqld[19074]: and this may fail.
Feb 26 06:25:45 db-slave mysqld[19074]:
Feb 26 06:25:45 db-slave mysqld[19074]: key_buffer_size=402653184
Feb 26 06:25:45 db-slave mysqld[19074]: read_buffer_size=2093056
Feb 26 06:25:45 db-slave mysqld[19074]: max_used_connections=100
Feb 26 06:25:45 db-slave mysqld[19074]: max_connections=500
Feb 26 06:25:45 db-slave mysqld[19074]: threads_connected=75
Feb 26 06:25:45 db-slave mysqld[19074]: It is possible that mysqld could use up to
Feb 26 06:25:45 db-slave mysqld[19074]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2439212 K
Feb 26 06:25:45 db-slave mysqld[19074]: bytes of memory
Feb 26 06:25:45 db-slave mysqld[19074]: Hope that's ok; if not, decrease some variables in the equation.
Feb 26 06:25:45 db-slave mysqld[19074]:
Feb 26 06:25:45 db-slave mysqld[19074]: thd=0x90fc7548
Feb 26 06:25:45 db-slave mysqld[19074]: Attempting backtrace. You can use the following information to find out
Feb 26 06:25:45 db-slave mysqld[19074]: where mysqld died. If you see no messages after this, something went
Feb 26 06:25:45 db-slave mysqld[19074]: terribly wrong...
Feb 26 06:25:45 db-slave mysqld[19074]: Cannot determine thread, fp=0x871e275c, backtrace may not be correct.
Feb 26 06:25:45 db-slave mysqld[19074]: Stack range sanity check OK, backtrace follows:
Feb 26 06:25:45 db-slave mysqld[19074]: 0x818f37c
Feb 26 06:25:45 db-slave mysqld[19074]: 0xffffe420
Feb 26 06:25:45 db-slave mysqld[19074]: 0x863bfc4
Feb 26 06:25:45 db-slave mysqld[19074]: 0x82019ac
Feb 26 06:25:45 db-slave mysqld[19074]: 0x8202b47
Feb 26 06:25:45 db-slave mysqld[19074]: 0x819f627
Feb 26 06:25:45 db-slave mysqld[19074]: 0x81a9257
Feb 26 06:25:45 db-slave mysqld[19074]: 0x81a9fd8
Feb 26 06:25:45 db-slave mysqld[19074]: 0x81aa924
Feb 26 06:25:45 db-slave mysqld[19074]: 0xb7faeced
Feb 26 06:25:45 db-slave mysqld[19074]: 0xb7defdde
Feb 26 06:25:45 db-slave mysqld[19074]: New value of fp=(nil) failed sanity check, terminating stack trace!
Feb 26 06:25:45 db-slave mysqld[19074]: Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
Feb 26 06:25:45 db-slave mysqld[19074]: stack trace is much more helpful in diagnosing the problem, so please do
Feb 26 06:25:45 db-slave mysqld[19074]: resolve it
Feb 26 06:25:45 db-slave mysqld[19074]: Trying to get some variables.
Feb 26 06:25:45 db-slave mysqld[19074]: Some pointers may be invalid and cause the dump to abort...
Feb 26 06:25:45 db-slave mysqld[19074]: thd->query at (nil)  is invalid pointer
Feb 26 06:25:45 db-slave mysqld[19074]: thd->thread_id=3586
Feb 26 06:25:45 db-slave mysqld[19074]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Feb 26 06:25:45 db-slave mysqld[19074]: information that should help you find out what is causing the crash.
[27 Feb 2006 10:38] Valeriy Kravchuk
Thank you for a problem report. Please, describe your upgrade procedure. Have you dumped and reloaded your data in 5.0.18?
[27 Feb 2006 10:58] Steve Simitzis
I did not dump and reload the data, as we cannot afford that amount of downtime. I simply used Debian's apt-get to upgrade the software.

Also, I upgraded both databases this way: the main db and the slave db, and only the slave is (so far) having the problem.
[10 Mar 2006 9:29] Valeriy Kravchuk
Please, send the uname -a results from both your master and slave.
[10 Mar 2006 9:33] Steve Simitzis
Slave:

2 /home/steve: db-slave> uname -a
Linux db-slave 2.6.11-1-686-smp #1 SMP Mon Jun 20 20:18:45 MDT 2005 i686 GNU/Linux

Master:

2 /home/steve: db> uname -a
Linux db 2.6.12.1-bigmem-p4-smp #1 SMP Mon Jun 27 20:22:42 PDT 2005 i686 GNU/Linux
[10 Mar 2006 10:29] Valeriy Kravchuk
Sorry, forgot to ask: glibc versions might be also useful.
[10 Mar 2006 10:36] Steve Simitzis
glibc-2.3.5-3 on both
[10 Mar 2006 15:45] Valeriy Kravchuk
Please, describe your hardware in more details (especially slave). Amount of RAM, number and model of CPUs?
[10 Mar 2006 21:10] Steve Simitzis
Slave: 4GB of RAM, dual Xeon 2.8GHz, two pairs of mirrored drives on a Megaraid card.

Main DB: 8GB of RAM, dual Xeon 3.6GHz, root drive is mirrored, and database drive is RAID 0+1, also on a Megaraid card.

log files live on the same drives as the database.
[13 Mar 2006 11:52] Holger S.
Hello,

got the same problem on Debian Sarge. It seemes to only happen when the server is configured not to log anything - I commented out "log-bin = ..." in my config cause binlogs  would grow some GBytes/Day and from that time on, "flush logs" always crashes the server.

This is my config that causes the server 5.0.18 (installed from package provided by debian.org (testing) )to crash on "flush logs":

#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "/var/lib/mysql/my.cnf" to set server-specific options or
# - "~/.my.cnf" to set user-specific options.
# 
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port		= 3306
socket		= /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket		= /var/run/mysqld/mysqld.sock
nice		= 0

[mysqld]
#
# * Basic Settings
#
user		= mysql
pid-file	= /var/run/mysqld/mysqld.pid
socket		= /var/run/mysqld/mysqld.sock
port		= 3306
basedir		= /usr
datadir		= /var/lib/mysql
tmpdir		= /tmp
language	= /usr/share/mysql/english
skip-external-locking
#
# For compatibility to other Debian packages that still use
# libmysqlclient10 and libmysqlclient12.
old_passwords	= 1
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address		= 127.0.0.1
#
# * Fine Tuning
#
key_buffer		= 128M
max_allowed_packet	= 64M
thread_stack		= 128K
max_heap_table_size	= 256M
#
# * Query Cache Configuration
#
query_cache_limit	= 1048576
query_cache_size        = 16777216
query_cache_type        = 1
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
#log		= /var/log/mysql.log
#log		= /var/log/mysql/mysql.log
#
# Error logging goes to syslog. This is a Debian improvement :)
#
# Here you can see queries with especially long duration
#log-slow-queries	= /var/log/mysql/mysql-slow.log
#
# The following can be used as easy to replay backup logs or for replication.
#server-id		= 1
#log-bin			= /var/log/mysql/mysql-bin.log
expire-logs-days	= 20
max_binlog_size         = 104857600
#binlog-do-db		= include_database_name
#binlog-ignore-db	= include_database_name
#
# * BerkeleyDB
#
# According to an MySQL employee the use of BerkeleyDB is now discouraged
# and support for it will probably cease in the next versions.
skip-bdb
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# If you want to enable SSL support (recommended) read the manual or my
# HOWTO in /usr/share/doc/mysql-server/SSL-MINI-HOWTO.txt.gz
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem

[mysqldump]
quick
quote-names
max_allowed_packet	= 16M

[mysql]
#no-auto-rehash	# faster start of mysql but no tab completition

[isamchk]
key_buffer		= 16M

#
# * NDB Cluster
#
# See /usr/share/doc/mysql-server-*/README.Debian for more information.
#
# The following configuration is read by the ndbd storage daemons,
# not from the ndb_mgmd management daemon.
#
# [MYSQL_CLUSTER]
# ndb-connectstring=127.0.0.1

-> END config

removing the "#" infront of the line "#log-bin = /var/log/mysql/mysql-bin.log" and restarting the server also removes the crash on flush logs.

Happens on both of my machines:
AMD 3200 (2GB RAM) and Pentium IV 2400 (512MB RAM) either, both debian sarge and package called mysql-server-5.0 from debian testing installed.

Hope that helps
[14 Mar 2006 16:31] Valeriy Kravchuk
Please, try to use MySQL's binaries of 5.0.19 and inform about any results.
[14 Mar 2006 20:24] Holger S.
Still the same:

debian:/etc# mysql -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.0.19-standard

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> flush logs;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql> 

Using same configuration i posted above.
When using default  mysql config and switching of all loggings, the error does not occure. Please try out my exact config - seemes that other variables take influence too.

error-log of mysqld:

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=134217728
read_buffer_size=131072
max_used_connections=1
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 = 348671 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x89c23a0
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=0xbfafeb28, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x80a28d7
0x82ed718
0x82b4061
0x810b32b
0x810bb6b
0x810cbc8
0x80bc789
0x80b7de2
0x80bb40a
0x80b2fd6
0x80b2874
0x80b1d84
0x82eaecc
0x831480a
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 0x89cd8a0 = flush logs
thd->thread_id=1
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
060314 21:21:03  mysqld restarted
060314 21:21:03  InnoDB: Started; log sequence number 0 43655
060314 21:21:03 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.19-standard'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Edition - Standard (GPL)
[15 Mar 2006 13:38] Valeriy Kravchuk
Can it be so that your logs are owned by other user/group than runs mysqld?
[16 Mar 2006 20:45] Holger S.
The user that runs mysql-server is "mysql", the logfiles ar owned by user "mysql and group "adm".
[16 Mar 2006 20:52] Steve Simitzis
My log files are also owned by the correct user and group: mysql:mysql
[17 Mar 2006 7:33] Steve Simitzis
So am I correct in understanding that the workaround is to add log-bin to my configuration on the slave server?
[15 Apr 2006 21:05] Alessandro Polverini
Hello,
I've the same problem: server crashing while executing flush-logs.
My platform is Etch AMD64, kernel 2.6.16-1-amd64-k8-smp and libc6-2.3.6-3.

I can also confirm that enabling logs-bin is a working workaround for now.
[22 Apr 2006 16:15] Valeriy Kravchuk
Bug #18553 was marked as a duplicate of this one.

Can you, please, try to repeat with a newer version, 5.0.20a, and inform about the results. Is it just enough to install without my.cnf at all and execute FLUSH LOGS to get the crash?

I am not able to repeat the problem that way, but I am not on Debian and not on AMD64. Looks like yet another platform-specific bug...
[25 Apr 2006 15:14] [ name withheld ]
I am on i386 and with 5.0.18, 5.0.19, and 5.0.20 on Debian I get the same repeatable crash.
[27 Apr 2006 7:39] Alessandro Polverini
I can confirm the problem is still present in debian version 5.0.20a-1
[22 May 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".
[22 May 2006 23:24] Alessandro Polverini
I installed version 5.0.21-2 and the problem persist
[22 May 2006 23:25] Alessandro Polverini
I would be grateful if you can reopen the bug
[31 May 2006 20:30] Valeriy Kravchuk
All reporters:

What exact version of threads library do you have on your Debian installations? You can get it with:

getconf GNU_LIBPTHREAD_VERSION
[1 Jun 2006 0:36] Alessandro Polverini
NPTL 2.3.6
[1 Jun 2006 17:16] [ name withheld ]
NPTL 0.60 on 1 server
linuxthreads-0.10 on another server
[2 Jun 2006 15:36] Erik Meitner
Same problem here. 
Debian Sarge, with mysql-5-server 5.0.20-0bpo1 (from backports.org)
Linux sage 2.4.31-dbnode #1 Mon Dec 26 09:42:09 CST 2005 i686 GNU/Linux
linuxthreads-0.10
log permissions correct.
glibc 2.3.2.ds1-22sa
Turning on logs-bin does prevent crashes during flush-logs.
[8 Jun 2006 23:01] Christian Hammers
I can now also reproduce it:

(gdb) bt
#0  0x00000000008037ed in reinit_io_cache ()
#1  0x00000000005d87a4 in MYSQL_LOG::find_log_pos ()
#2  0x00000000005db170 in MYSQL_LOG::purge_logs_before_date ()
#3  0x00000000005dc17e in MYSQL_LOG::rotate_and_purge ()
#4  0x000000000057a540 in reload_acl_and_cache ()
#5  0x000000000057e3c7 in mysql_execute_command ()
#6  0x0000000000583c3d in mysql_parse ()
#7  0x0000000000584162 in dispatch_command ()
#8  0x0000000000585085 in do_command ()
#9  0x00000000005859e7 in handle_one_connection ()
#10 0x00002b07739beb1c in start_thread () from /lib/libpthread.so.0
#11 0x00002b077427a9c2 in clone () from /lib/libc.so.6
#12 0x0000000000000000 in ?? ()

Distro: Debian GNU/Linux unstable
uname -a: Linux app109 2.6.16-2-amd64-k8 #1 Mon May 22 14:00:22 UTC 2006 x86_64 GNU/Linux
libc6: 2.3.6
mysql: 5.0.22
getconf GNU_LIBPTHREAD_VERSION: NPTL 2.3.6
strace: will be uploaded separately

The bug is still in state "Need Feedback", what do you want to know?

bye,

-christian-
[8 Jun 2006 23:07] Christian Hammers
I am not allowed to attach a file to the bug report. Silly configuration, isn't it?
Get http://www.lathspell.de/linux/debian/mysql/Bug17733.strace.bz2

BTW, additional info:
CPU: AMD Athlon(tm) 64 Processor 3000+
Memory: 1GB

mysql> SHOW VARIABLES LIKE "%log%";
+---------------------------------+----------------------+
| Variable_name                   | Value                |
+---------------------------------+----------------------+
| back_log                        | 50                   | 
| binlog_cache_size               | 32768                | 
| expire_logs_days                | 20                   | 
| innodb_flush_log_at_trx_commit  | 1                    | 
| innodb_locks_unsafe_for_binlog  | OFF                  | 
| innodb_log_arch_dir             |                      | 
| innodb_log_archive              | OFF                  | 
| innodb_log_buffer_size          | 1048576              | 
| innodb_log_file_size            | 5242880              | 
| innodb_log_files_in_group       | 2                    | 
| innodb_log_group_home_dir       | ./                   | 
| innodb_mirrored_log_groups      | 1                    | 
| log                             | OFF                  | 
| log_bin                         | OFF                  | 
| log_bin_trust_function_creators | OFF                  | 
| log_error                       |                      | 
| log_slave_updates               | OFF                  | 
| log_slow_queries                | OFF                  | 
| log_warnings                    | 1                    | 
| max_binlog_cache_size           | 18446744073709551615 | 
| max_binlog_size                 | 104857600            | 
| max_relay_log_size              | 0                    | 
| relay_log_purge                 | ON                   | 
| relay_log_space_limit           | 0                    | 
| sync_binlog                     | 0                    | 
+---------------------------------+----------------------+
25 rows in set (0.00 sec)

So note that there is no logfile defined at all :)

$ ls -al /var/log/mysql/ 
insgesamt 8
drwxr-s---  2 mysql adm  4096 2006-05-06 19:00 ./
drwxr-xr-x 12 root  root 4096 2006-06-08 06:29 ../

bye,

-christian-
[24 Jun 2006 7:54] Oliver Neumann
Same problem with version 5.0.22 (from dotdeb.org, backport site for debian sarge).

getconf GNU_LIBPTHREAD_VERSION: NPTL 0.60
uname -a: Linux xxxxxxxxxxxxxxxxx 2.6.16.20 #1 SMP Wed Jun 7 16:36:48 CEST 2006 i686 GNU/Linux
[3 Jul 2006 12:40] Valeriy Kravchuk
Thank you for your patience and persistance. I was able to repeat the behaviour you described on 5.0.24-BK build on SuSE Linux 9.3. All you need to do to get this crash is to set expire_logs_days to something > 0 (non-default):

openxs@suse:~/dbs/5.0> bin/mysql -uroot test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.0.24

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> show variables like '%log%';
+---------------------------------+------------+
| Variable_name                   | Value      |
+---------------------------------+------------+
| back_log                        | 50         |
| binlog_cache_size               | 32768      |
| expire_logs_days                | 0          |
| innodb_flush_log_at_trx_commit  | 1          |
| innodb_locks_unsafe_for_binlog  | OFF        |
| innodb_log_arch_dir             |            |
| innodb_log_archive              | OFF        |
| innodb_log_buffer_size          | 1048576    |
| innodb_log_file_size            | 5242880    |
| innodb_log_files_in_group       | 2          |
| innodb_log_group_home_dir       | ./         |
| innodb_mirrored_log_groups      | 1          |
| log                             | OFF        |
| log_bin                         | OFF        |
| log_bin_trust_function_creators | OFF        |
| log_error                       |            |
| log_queries_not_using_indexes   | OFF        |
| log_slave_updates               | OFF        |
| log_slow_queries                | OFF        |
| log_warnings                    | 1          |
| max_binlog_cache_size           | 4294967295 |
| max_binlog_size                 | 1073741824 |
| max_relay_log_size              | 0          |
| relay_log_purge                 | ON         |
| relay_log_space_limit           | 0          |
| sync_binlog                     | 0          |
+---------------------------------+------------+
26 rows in set (0.01 sec)

mysql> flush logs;
Query OK, 0 rows affected (0.01 sec)

mysql> flush logs;
Query OK, 0 rows affected (0.00 sec)

mysql> set global expire_logs_days = 3;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like '%log%';
+---------------------------------+------------+
| Variable_name                   | Value      |
+---------------------------------+------------+
| back_log                        | 50         |
| binlog_cache_size               | 32768      |
| expire_logs_days                | 3          |
| innodb_flush_log_at_trx_commit  | 1          |
| innodb_locks_unsafe_for_binlog  | OFF        |
| innodb_log_arch_dir             |            |
| innodb_log_archive              | OFF        |
| innodb_log_buffer_size          | 1048576    |
| innodb_log_file_size            | 5242880    |
| innodb_log_files_in_group       | 2          |
| innodb_log_group_home_dir       | ./         |
| innodb_mirrored_log_groups      | 1          |
| log                             | OFF        |
| log_bin                         | OFF        |
| log_bin_trust_function_creators | OFF        |
| log_error                       |            |
| log_queries_not_using_indexes   | OFF        |
| log_slave_updates               | OFF        |
| log_slow_queries                | OFF        |
| log_warnings                    | 1          |
| max_binlog_cache_size           | 4294967295 |
| max_binlog_size                 | 1073741824 |
| max_relay_log_size              | 0          |
| relay_log_purge                 | ON         |
| relay_log_space_limit           | 0          |
| sync_binlog                     | 0          |
+---------------------------------+------------+
26 rows in set (0.00 sec)

mysql> flush logs;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>
Number of processes running now: 0
060703 14:29:18  mysqld restarted

mysql> exit
Bye
openxs@suse:~/dbs/5.0> tail -50 var/suse.err
...
060703 14:28:45 [Note] /home/openxs/dbs/5.0/libexec/mysqld: ready for connection
s.
Version: '5.0.24'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
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=8388600
read_buffer_size=131072
max_used_connections=1
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 = 225791
 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8b73768
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=0x428cf71c, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81b1796
0xffffe420
(nil)
0x8233bb6
Stack trace seems successful - bottom reached
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 0x8bb1938 = flush logs
thd->thread_id=1
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
060703 14:29:18  mysqld restarted
060703 14:29:18  InnoDB: Started; log sequence number 0 1029117167
...
[3 Jul 2006 12:45] Valeriy Kravchuk
Same result for 5.1.12-BK.
[20 Jul 2006 19:11] Valeriy Kravchuk
Bug #20541 was marked as a duplicate of this one.
[11 Aug 2006 19:06] Chad MILLER
I cannot reproduce with today's 5.0 source on Debian testing/unstable x86-64 or on Ubuntu Dapper x86 .

#
# Bug#17733: Flushing logs causes daily server crash
#
show variables like '%log%';
flush logs;
set global expire_logs_days = 3;
flush logs;
show variables like '%log%';
set global expire_logs_days = 0;
flush logs;
[3 Sep 2006 16:31] Christian Hammers
Chad, which one is "todays version" exactly? I tried 5.0.24a and was able to reproduce the problem immediately.
[5 Sep 2006 7:48] Markus Pflueger
Hello Everyone,
i also experienced this problem after upgrading from a 4.x Database to a 5.x database (sql version). What i found out is if you have enabled the "expire_logs_days" variable in /etc/mysql/my.cnf or (debian-log-rotate.conf) but you explicitely have disabled "log-bin                 = /var/log/mysql/mysql-bin.log" in the /etc/mysql/my.cnf file then the crash will happen if you do a "mysqladmin flush logs".

1. With expire_log_days enabled, but explicitely commented out #log-bin (see log_bin Value "OFF"):

mysql> show variables like '%log%';
+---------------------------------+------------+
| Variable_name                   | Value      |
+---------------------------------+------------+
| back_log                        | 50         |
| binlog_cache_size               | 32768      |
| expire_logs_days                | 2          |
| innodb_flush_log_at_trx_commit  | 1          |
| innodb_locks_unsafe_for_binlog  | OFF        |
| innodb_log_arch_dir             |            |
| innodb_log_archive              | OFF        |
| innodb_log_buffer_size          | 1048576    |
| innodb_log_file_size            | 5242880    |
| innodb_log_files_in_group       | 2          |
| innodb_log_group_home_dir       | ./         |
| innodb_mirrored_log_groups      | 1          |
| log                             | OFF        |
| log_bin                         | OFF        |
| log_bin_trust_function_creators | OFF        |
| log_error                       |            |
| log_slave_updates               | OFF        |
| log_slow_queries                | OFF        |
| log_warnings                    | 1          |
| max_binlog_cache_size           | 4294967295 |
| max_binlog_size                 | 104857600  |
| max_relay_log_size              | 0          |
| relay_log_purge                 | ON         |
| relay_log_space_limit           | 0          |
| sync_binlog                     | 0          |
+---------------------------------+------------+
25 rows in set (0.01 sec)

mysql> flush logs;
ERROR 2013 (HY000): Lost connection to MySQL server during query

2. With expire_log_days enabled, and explicitely "UN"commented log-bin (see log_bin VALUE "ON"):

mysql> show variables like '%log%';
+---------------------------------+------------+
| Variable_name                   | Value      |
+---------------------------------+------------+
| back_log                        | 50         |
| binlog_cache_size               | 32768      |
| expire_logs_days                | 2          |
| innodb_flush_log_at_trx_commit  | 1          |
| innodb_locks_unsafe_for_binlog  | OFF        |
| innodb_log_arch_dir             |            |
| innodb_log_archive              | OFF        |
| innodb_log_buffer_size          | 1048576    |
| innodb_log_file_size            | 5242880    |
| innodb_log_files_in_group       | 2          |
| innodb_log_group_home_dir       | ./         |
| innodb_mirrored_log_groups      | 1          |
| log                             | OFF        |
| log_bin                         | ON         |
| log_bin_trust_function_creators | OFF        |
| log_error                       |            |
| log_slave_updates               | OFF        |
| log_slow_queries                | OFF        |
| log_warnings                    | 1          |
| max_binlog_cache_size           | 4294967295 |
| max_binlog_size                 | 104857600  |
| max_relay_log_size              | 0          |
| relay_log_purge                 | ON         |
| relay_log_space_limit           | 0          |
| sync_binlog                     | 0          |
+---------------------------------+------------+
25 rows in set (0.00 sec)

mysql> flush logs;
Query OK, 0 rows affected (0.10 sec)

Hope this helps everyone resolving this "NONE" Bug!
Its more an configuration problem.

So the variable "expire_logs_days" is checked even if "log-bin" is not enabled. This causes the crash!

Have a nice day everyone!
[3 Oct 2006 12:46] Christian Hammers
Any news?
[1 Nov 2006 18:23] Valeriy Kravchuk
Re-verified with latest 5.0.29-BK (ChangeSet@1.2281, 2006-11-01 16:14:49+01:00). Same results:

openxs@suse:~/dbs/5.0> bin/mysqld_safe &
[1] 9702
openxs@suse:~/dbs/5.0> Starting mysqld daemon with databases from /home/openxs/d
bs/5.0/var

openxs@suse:~/dbs/5.0> bin/mysql -uroot test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.0.29-debug Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> set global expire_logs_days = 3;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'expire%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| expire_logs_days | 3     |
+------------------+-------+
1 row in set (0.00 sec)

mysql> flush logs;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>
Number of processes running now: 0
061101 18:04:32  mysqld restarted
[17 Nov 2006 11:21] Kristofer Pettersson
prog report:
mysql> set global expire_logs_days = 3;flush logs;
ERROR 2006 (HY000): MySQL server has gone away

Crash can be avoided if info->request_pos pointer is validated before call to my_b_tell(info):

mf_iocache.c:
.
.
324: /* If the whole file is in memory, avoid flushing to disk */
325:  if ( info->request_pos && ! clear_cache &&
           seek_offset >= info->pos_in_file &&
           seek_offset <= my_b_tell(info))
      {
.
.

Now, investingating why this function was called without proper parameters.
[9 Dec 2006 18:35] Paul Dubois
Noted in 5.0.32, 5.1.15 changelogs.

FLUSH LOGS or mysqladmin flush-logs caused a server crash if the
binary log was not open.
[22 May 2007 11:20] Valeriy Kravchuk
Bug #27924 is a duplicate of this one.
[23 May 2007 20:32] time e.less
This bug also hit us for a while. I put this into the top of the script that attempts to flush logs:

# script seems to be crashing mysql?
echo "exiting without doing anything"
exit 0;

Needless to say, this fixed the problem. This is a slave that doesn't have binary logs anyway, so I didn't mind doing it.

It seems like it should be a fairly easy thing for MySQLd to take a "flush logs" that doesn't do anything and... not do anything, rather than segfault. Or for Debian to not issue a "flush logs" on a non-master machine.
[24 Feb 2009 13:17] Chris Wilson
This bug was fixed in 5.0.33 (http://dev.mysql.com/doc/refman/5.0/en/releasenotes-cs-5-0-33.html).

I wish that whoever closed this bug had told us that, so that I would not have had to search for it.

This issue affects Ubuntu Dapper Drake (6.06 LTS), which comes with 5.0.22-Debian_0ubuntu6.06.10. I have opened bug 333813 (https://bugs.launchpad.net/bugs/333813) against Dapper.