Hello,
since updating my amd64-sarge today (March 14, 2005), the mysqld daeman
segfaults on QUITs from clients. As it will automatically restart, this might
not be noticed immediately in a client that is performing automatic
reconnects. But at least the syslog reveals that something's been going wrong
(see below). This behavior can be reproduced with both mysql branches
available as binary amd64 packages (4.0 and 4.1). There are some reports on
observing this bug in other distributions before, e.g.
http://bugs.mysql.com/bug.php?id=2426, where it apparently turned out to be
some library mismatch.
Can anyone confirm this bug for the current amd64 binary packages?
Regards,
Tom
Mar 14 11:25:38 ite167 mysqld[3296]: mysqld got signal 11;
Mar 14 11:25:38 ite167 mysqld[3296]: This could be because you hit a bug. It
is also possible that this binary
Mar 14 11:25:38 ite167 mysqld[3296]: or one of the libraries it was linked
against is corrupt, improperly built,
Mar 14 11:25:38 ite167 mysqld[3296]: or misconfigured. This error can also be
caused by malfunctioning hardware.
Mar 14 11:25:38 ite167 mysqld[3296]: We will try our best to scrape up some
info that will hopefully help diagnose
Mar 14 11:25:38 ite167 mysqld[3296]: the problem, but since we have already
crashed, something is definitely wrong
Mar 14 11:25:38 ite167 mysqld[3296]: and this may fail.
Mar 14 11:25:38 ite167 mysqld[3296]:
Mar 14 11:25:38 ite167 mysqld[3296]: key_buffer_size=16777216
Mar 14 11:25:38 ite167 mysqld[3296]: read_buffer_size=131072
Mar 14 11:25:38 ite167 mysqld[3296]: max_used_connections=1
Mar 14 11:25:38 ite167 mysqld[3296]: max_connections=100
Mar 14 11:25:38 ite167 mysqld[3296]: threads_connected=0
Mar 14 11:25:38 ite167 mysqld[3296]: It is possible that mysqld could use up
to
Mar 14 11:25:38 ite167 mysqld[3296]: key_buffer_size + (read_buffer_size +
sort_buffer_size)*max_connections = 233983 K
Mar 14 11:25:38 ite167 mysqld[3296]: bytes of memory
Mar 14 11:25:38 ite167 mysqld[3296]: Hope that's ok; if not, decrease some
variables in the equation.
Mar 14 11:25:38 ite167 mysqld[3296]:
Mar 14 11:25:38 ite167 mysqld_safe[3316]: Number of processes running now: 0
Mar 14 11:25:38 ite167 mysqld_safe[3318]: restarted
Mar 14 11:25:39 ite167 mysqld[3321]: 050314 11:25:39 InnoDB: Database was
not shut down normally!
Mar 14 11:25:39 ite167 mysqld[3321]: InnoDB: Starting crash recovery.
Mar 14 11:25:39 ite167 mysqld[3321]: InnoDB: Reading tablespace information
from the .ibd files...
Mar 14 11:25:39 ite167 mysqld[3321]: InnoDB: Restoring possible half-written
data pages from the doublewrite
Mar 14 11:25:39 ite167 mysqld[3321]: InnoDB: buffer...
Mar 14 11:25:39 ite167 mysqld[3321]: 050314 11:25:39 InnoDB: Starting log
scan based on checkpoint at
Mar 14 11:25:39 ite167 mysqld[3321]: InnoDB: log sequence number 0 44074.
Mar 14 11:25:39 ite167 mysqld[3321]: InnoDB: Doing recovery: scanned up to
log sequence number 0 44074
Mar 14 11:25:39 ite167 mysqld[3321]: InnoDB: Last MySQL binlog file position
0 79, file name /var/log/mysql/mysql-bin.000009
Mar 14 11:25:39 ite167 mysqld[3321]: 050314 11:25:39 InnoDB: Flushing
modified pages from the buffer pool...
Mar 14 11:25:39 ite167 mysqld[3321]: 050314 11:25:39 InnoDB: Started; log
sequence number 0 44074
Mar 14 11:25:39 ite167 mysqld[3321]: /usr/sbin/mysqld: ready for connections.
Mar 14 11:25:39 ite167 mysqld[3321]: Version: '4.1.10a-Debian_1-log' socket:
'/var/run/mysqld/mysqld.sock' port: 3306 Source distributi
--
To UNSUBSCRIBE, email to debian-amd64-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org