| 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: | |
| 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
[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.
