MySQL Bugs: #37126: Server crashes with datetime and order by desc

Bug #37126	Server crashes with datetime and order by desc
Submitted:	1 Jun 2008 10:51	Modified:	28 May 2009 9:00
Reporter:	Scott Muller	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	5.1.25, 5.0.45 (&5.0.51a), 5.0.67 SUSE MySQL RPM, 5.1.26	OS:	Linux (SUSE x86_64)
Assigned to:		CPU Architecture:	Any

Description:
Server crashes on queries on table with datetime field and compound index where query has "order by desc" clause 

How to repeat:
DROP TABLE IF EXISTS `test`;
CREATE TABLE `test` (
  `id` bigint(20),
  `date_time` datetime,
  `msecs` int(10),
  PRIMARY KEY  (`id`),
  KEY `time` (`date_time`,`msecs`)
) ENGINE=MyISAM ;

INSERT INTO `test` VALUES (35279793,'2008-05-22 22:01:28',277),(35279794,'2008-05-22 22:01:28',277),(35279795,'2008-05-22 22:01:28',277),(35279796,'2008-05-22 22:01:28',277);

 select * from test where date_time > "2008-05-22 22:01:00" and date_time < "2008-05-22 22:05:00" order by date_time desc; 

ERROR 2013 (HY000): Lost connection to MySQL server during query

Thank you for the report.

I can not repeat described behavior. Please provide your configuration file.

Config file

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

Please try with our newest version: MySQL 5.0.51b

I have not been able to locate a 5.0.51b release but have confirmed that the problem occurs also with the 5.1.24-rc-community MySQL Community Server release.

Additionally, the OS details are as follows (if it helps):
jacob:/var/lib/mysql/mysql # uname -a
Linux jacob 2.6.22.5-10-default #1 SMP 2007/09/03 12:07:40 UTC x86_64 x86_64 x86_64 GNU/Linux

I can not repeat this bug on recent versions neither on Linux nor on Windows:

C:\Program Files\MySQL\MySQL Server 5.0\bin>mysql -uroot -proot -P3310 test
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 6
Server version: 5.1.25-rc-community MySQL Community Server (GPL)

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

mysql> DROP TABLE IF EXISTS `test`;
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> CREATE TABLE `test` (
    ->   `id` bigint(20),
    ->   `date_time` datetime,
    ->   `msecs` int(10),
    ->   PRIMARY KEY  (`id`),
    ->   KEY `time` (`date_time`,`msecs`)
    -> ) ENGINE=MyISAM ;
Query OK, 0 rows affected (0.08 sec)

mysql> INSERT INTO `test` VALUES (35279793,'2008-05-22 22:01:28',277),(35279794,
'2008-05-22
    '> 22:01:28',277),(35279795,'2008-05-22 22:01:28',277),(35279796,'2008-05-22
 22:01:28',277);
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql>  select * from test where date_time > "2008-05-22 22:01:00" and date_time
 < "2008-05-22
    "> 22:05:00" order by date_time desc;
+----------+---------------------+-------+
| id       | date_time           | msecs |
+----------+---------------------+-------+
| 35279796 | 2008-05-22 22:01:28 |   277 |
| 35279795 | 2008-05-22 22:01:28 |   277 |
| 35279794 | 2008-05-22 22:01:28 |   277 |
| 35279793 | 2008-05-22 22:01:28 |   277 |
+----------+---------------------+-------+
4 rows in set (0.06 sec)

mysql> exit
Bye

C:\Program Files\MySQL\MySQL Server 5.0\bin>mysql -uroot -proot -P3308 test
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 9
Server version: 5.0.60-enterprise-gpl-nt-log MySQL Enterprise Server (GPL)

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

mysql> DROP TABLE IF EXISTS `test`;
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> CREATE TABLE `test` (
    ->   `id` bigint(20),
    ->   `date_time` datetime,
    ->   `msecs` int(10),
    ->   PRIMARY KEY  (`id`),
    ->   KEY `time` (`date_time`,`msecs`)
    -> ) ENGINE=MyISAM ;
Query OK, 0 rows affected (0.06 sec)

mysql> INSERT INTO `test` VALUES (35279793,'2008-05-22 22:01:28',277),(35279794,
'2008-05-22
    '> 22:01:28',277),(35279795,'2008-05-22 22:01:28',277),(35279796,'2008-05-22
 22:01:28',277);
Query OK, 4 rows affected (0.01 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql>  select * from test where date_time > "2008-05-22 22:01:00" and date_time
 < "2008-05-22
    "> 22:05:00" order by date_time desc;
+----------+---------------------+-------+
| id       | date_time           | msecs |
+----------+---------------------+-------+
| 35279796 | 2008-05-22 22:01:28 |   277 |
| 35279795 | 2008-05-22 22:01:28 |   277 |
| 35279794 | 2008-05-22 22:01:28 |   277 |
| 35279793 | 2008-05-22 22:01:28 |   277 |
+----------+---------------------+-------+
4 rows in set (0.08 sec)

Please, check 5.1.25, it is already released officially.

hi,

i have nearly the same problem. but for me it seems somehow related to indexes. the server (mysql 5.0.45 on opensuse 10.3) crashes if order by desc is used in an select statement on a column that has at least one index set. it does not need to be a datetime column. if i either remove the desc keyword or drop the index or remove the force index part of the query the server does not crash.

br

Hi. I have checked the 5.1.25 release and this version crashes too (see below) . I can also confirm that if I remove the 'desc' keyword or drop the time index, the server does not crash.

I have now checked this on 4 x86_64 (3 opteron and 1 turion notebook) servers running SuSE and all have exhibited this behaviour.

-----------------------------------------

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.1.25-rc-community MySQL Community Server (GPL)

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

mysql> use test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> DROP TABLE IF EXISTS `test`;
Query OK, 0 rows affected (0.00 sec)

mysql> CREATE TABLE `test` (
    ->   `id` bigint(20),
    ->   `date_time` datetime,
    ->   `msecs` int(10),
    ->   PRIMARY KEY  (`id`),
    ->   KEY `time` (`date_time`,`msecs`)
    -> ) ENGINE=MyISAM ;
Query OK, 0 rows affected (0.06 sec)

mysql> INSERT INTO `test` VALUES (35279793,'2008-05-22 22:01:28',277),(35279794,'2008-05-22
    '> 22:01:28',277),(35279795,'2008-05-22 22:01:28',277),(35279796,'2008-05-22 22:01:28',277);
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql>  select * from test where date_time > "2008-05-22 22:01:00" and date_time < "2008-05-22
    "> 22:05:00" order by date_time desc;
ERROR 2013 (HY000): Lost connection to MySQL server during query

Thank you for the feedback.

You have quite large settings in my.cnf

Please indicate how much physical memory do you have.

Also please turn on log-error option, run test and provide us error log file.

The large my.cnf settings are from one of our 3 terabtye servers that is exhibiting this problem. It has 4 opteron cores (2xdual core) and 8 GB RAM.

Below is the my.cnf is from my notebook (also crashing the mysql server on this query). When I run the query on the notebook with log errors on, I get the following:

------------------mysqld.err--------------------------------

080629 11:01:22  InnoDB: Started; log sequence number 0 43655
080629 11:01:22 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.45'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  SUSE MySQL RPM
080629 11:01:54 - 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=258048
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 = 92783 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x21cc640
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=0x44088fe0, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
(nil)
New value of fp=0x21cc640 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 0x22064a0 = select * from test where date_time > "2008-05-22 22:01:00" and date_time < "2008-05-22
22:05:00" order by date_time desc
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.
080629 11:01:54  InnoDB: Started; log sequence number 0 43655
080629 11:01:54 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.45'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  SUSE MySQL RPM

-------------------------my.cnf---------------------------------
# Example MySQL config file for medium systems.
#
# This is for a system with little memory (32M - 64M) where MySQL plays
# an important part, or systems up to 128M where MySQL is used together with
# other programs (such as a web server)
#
# You can copy this file to
# /etc/my.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.
#
# In this file, you can use all long options that a program supports.
# If you want to know which options a program supports, run the program
# with the "--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
key_buffer = 16M
max_allowed_packet = 1M
table_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M
log-error

# Don't listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (via the "enable-named-pipe" option) will render mysqld useless!
#
#skip-networking

# Replication Master Server (default)
# binary logging is required for replication
# log-bin=mysql-bin

# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-id       = 1

# Replication Slave (comment out master section to use this)
#
# To configure this host as a replication slave, you can choose between
# two methods :
#
# 1) Use the CHANGE MASTER TO command (fully described in our manual) -
#    the syntax is:
#
#    CHANGE MASTER TO MASTER_HOST=<host>, MASTER_PORT=<port>,
#    MASTER_USER=<user>, MASTER_PASSWORD=<password> ;
#
#    where you replace <host>, <user>, <password> by quoted strings and
#    <port> by the master's port number (3306 by default).
#
#    Example:
#
#    CHANGE MASTER TO MASTER_HOST='125.564.12.1', MASTER_PORT=3306,
#    MASTER_USER='joe', MASTER_PASSWORD='secret';
#
# OR
#
# 2) Set the variables below. However, in case you choose this method, then
#    start replication for the first time (even unsuccessfully, for example
#    if you mistyped the password in master-password and the slave fails to
#    connect), the slave will create a master.info file, and any later
#    change in this file to the variables' values below will be ignored and
#    overridden by the content of the master.info file, unless you shutdown
#    the slave server, delete master.info and restart the slaver server.
#    For that reason, you may want to leave the lines below untouched
#    (commented) and instead use CHANGE MASTER TO (see above)
#
# required unique id between 2 and 2^32 - 1
# (and different from the master)
# defaults to 2 if master-host is set
# but will not function as a slave if omitted
#server-id       = 2
#
# The replication master for this slave - required
#master-host     =   <hostname>
#
# The username the slave will use for authentication when connecting
# to the master - required
#master-user     =   <username>
#
# The password the slave will authenticate with when connecting to
# the master - required
#master-password =   <password>
#
# The port the master is listening on.
# optional - defaults to 3306
#master-port     =  <port>
#
# binary logging - not required for slaves, but recommended
#log-bin=mysql-bin

# 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
#bdb_cache_size = 4M
#bdb_max_lock = 10000

# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = /var/lib/mysql/
#innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /var/lib/mysql/
#innodb_log_arch_dir = /var/lib/mysql/
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
#innodb_buffer_pool_size = 16M
#innodb_additional_mem_pool_size = 2M
# Set .._log_file_size to 25 % of buffer pool size
#innodb_log_file_size = 5M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50

# The safe_mysqld script
[safe_mysqld]
err-log=/var/lib/mysql/mysqld.log

[mysqldump]
quick
max_allowed_packet = 16M

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

[isamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[myisamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

Please, try to repeat with a newer version, 5.1.26, and inform about the results.

i've already tried to compile 5.0.51b from source (on opensuse 10.3 x86_64) but the problem is still there. version 5.1 is no option for our production environment.

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".

i can now confirm that the exactly the same problem still exists in 5.0.67 and 5.1.26 (openSuSE 10.3, x86_64). mysqld crashes.

I also have the same problem with my server Dual Quad Xeon, 8gb RAM, SCSI disk and SuSE 10.3 x64, MySQL 5.0.67 also x64 version.

081202 7:02:05 - mysqld got signal 7 ;
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=805306368
read_buffer_size=1048576
max_used_connections=2
max_connections=1000
threads_connected=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 5906432 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x157f490
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=0x44088fe0, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
(nil)
New value of fp=0x157f490 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 0x1581610 = SELECT id, seo_url
FROM script_users
WHERE id < 7500
AND active = 1
ORDER BY id DESC
LIMIT 1
thd->thread_id=14
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

Number of processes running now: 0
081202 07:02:05 mysqld restarted
081202 7:02:05 [Warning] option 'net_buffer_length': unsigned value 8388608 adjusted to 1048576
InnoDB: Log scan progressed past the checkpoint lsn 0 2466587
081202 7:02:05 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 0 2466841
081202 7:02:05 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
081202 7:02:05 InnoDB: Started; log sequence number 0 2466841
081202 7:02:05 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.67-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 SUSE MySQL RPM

We had the same problem here. The bug does not seem to be within the myaql server itself though. We did a software update which didn't change the MySQL version, but updated, among other things, the kernel and libmysql.
Don't know what did the trick, but it works now.

We also found 2 ways to work around the problem:

1. The problem obviously only shows up, when you have a query containing a comparison ( < or > ) and an ORDER BY [field] DESC.
So, if you change the ORDER BY clause to ORDER BY ([field] * -1) ASC, you will get the same result, but the MySQL server won't crash.
2. In our case, another thing worked: We had a DECIMAL field we used for the comparison as well as the ORDER BY. When we made a type cast to exactly the same type (i.e. CAST([field] AS DECIMAL(7,2)) ) it also worked (for whatever reason).

So, if you have no means or are not willing to update your system, you might also be able to work around the problem.

Kind regards

@[6 Jan 19:54] Christian Wellinghorst

Could you please provide a test case (create table, insert statements, queries) which provoke the crash on your side?. Thanks in advance.

Hi Folks!

My System has the same problem: OpenSuse 10.3 with mysql 5.0.45 (also tried .51a). Tried PHP 5.2.6 and 5.2.8. Problem is always the same - total crash (automatic restarted with mysql_safe) and many "Host gone away" warnings... .

The mysql-log shows on every crash one out of two querys:

SELECT logid FROM pphl_87751_logs WHERE ip='195.93.60.106' AND t_reload > 1232186237 ORDER BY t_reload DESC LIMIT 1

or

select id from jos_joomlawatch where (id < 91210 and browser is NULL) order by id desc

What these two have in comon is the "DESC" sort-order als some other users found out - and the comparison (</>)!

As the first query is started from pphlogger (a popular statistics-package) and the second comes from the "joomla-watch" statistics-addon (for joomla-cms) I disabled these two stats (better a running server with many visitors than a stumbeling site with some sort of messed-up statistics...).

It looks like some problem within the mysql core functions to me... .

As the "avoid certain querys"-strategy is no real solution I look forward to any suggestions how to fix that... .

Greetings from Germany

Thomas 1000

@Thomas 1000

Thank you for the feedback. Are you able to provide a dump file so we will able to run these offended queries?. The dump file could be attached as private if you wish. Thanks in advance.

@[6 Jan 21:25] Miguel Solorzano 

The test case initially provided by Scott Muller also caused our SQL Server to crash. I think this is a simple and good example to reproduce the error on affected machines.

kind regards

Christian,

thank you for the feedback. But nobody of us can repeat the problem with test case provided by Scott Muller, so we have to find additional circumstances with which bug is repeatable.

We have the same problem. We're using openSUSE 10.3 (X86-64) and MySQL 5.0.45-22.2 (RPM). As other posters described, the crash occurs with an SQL quey that contains a numeric comarison (< or >) and an ORDER BY ... DESC clause. I applied the workaround 2 from Christian Wellinghorst above [6 Jan 19:54] and it seems to work.

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".

opensuse 10.3 x64, mysql rpm 5.0.67, mediawiki 1.12.0

090209 16:16:35 - 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=262144
max_used_connections=2
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 = 93184 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x21e5970
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=0x440c9fe0, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
(nil)
New value of fp=0x21e5970 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 0x221f000 = /* SpecialAllpages::showChunk GiselaWeber */ SELECT page_title FROM `page` WHERE page_namespace = '0' AND (page_title < 'An') ORDER BY page_title DESC LIMIT 959,960
thd->thread_id=16
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

Number of processes running now: 0
090209 16:16:35 mysqld restarted
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
090209 16:16:36 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
090209 16:16:36 InnoDB: Started; log sequence number 1 3057199276
090209 16:16:36 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.67' socket: '/var/lib/mysql/mysql.sock' port: 3306 SUSE MySQL RPM

Same problem here: OpenSUSE 10.3, MySQL 5.0.45. We get a "Lost connection to MySQL server during query" on this query:

SELECT * from siteinformation WHERE siteid='1' ORDER BY timestamp DESC LIMIT 1

Table info:

CREATE TABLE `siteinformation` (
  `siteid` int(11) NOT NULL,
  `timestamp` timestamp NOT NULL default '1979-12-31 23:00:00',
  `processoris64bits` tinyint(4) NOT NULL default '-1',
  `processorvendor` varchar(255) NOT NULL default 'NA',
  `processorvendorid` varchar(255) NOT NULL default 'NA',
  `processorfamilyid` int(11) NOT NULL default '-1',
  `processormodelid` int(11) NOT NULL default '-1',
  `processorcachesize` int(11) NOT NULL default '-1',
  `numberlogicalcpus` tinyint(4) NOT NULL default '-1',
  `numberphysicalcpus` tinyint(4) NOT NULL default '-1',
  `totalvirtualmemory` int(11) NOT NULL default '-1',
  `totalphysicalmemory` int(11) NOT NULL default '-1',
  `logicalprocessorsperphysical` int(11) NOT NULL default '-1',
  `processorclockfrequency` int(11) NOT NULL default '-1',
  `description` varchar(255) NOT NULL default 'NA',
  KEY `siteid` (`siteid`,`timestamp`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Happens when there are more than one record with siteid='1'.

In our case, I wouldn't like to change the query. It's part of the cdash (www.cdash.org) code.

Ed Fuentetaja,

thank you for the feedback.

But version 5.0.45 is old. Please try current version 5.0.77 and if problem still exists provide minimal dump of data in the table bug is repeatable with: still can not repeat in my environment. Please also indicate which settings do you use.

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".

I spend about 6 hours trying to solve this very strange problem and now my MySQL server work without any problem and crashes (version 5.0.67)…

Some of these packages are definitely the key of success but I really cannot downgrade one my one to find which one is the right and which one is not so I suggest you to upgrade one by one and after every upgrade you need to restart MySQL server and try to execute problematic query and see what happened…

openSuSE 10.3  64bit

glib2-2.14.1-4.2.x86_64.rpm
glibc-32bit-2.6.1-18.3.x86_64.rpm
glibc-locale-2.6.1-18.3.x86_64.rpm
glibc-2.6.1-18.3.x86_64.rpm
glibc-devel-2.6.1-18.3.x86_64.rpm

or

audit-libs-32bit-1.5.5-13.4.x86_64.rpm
dbus-1-1.0.2-59.4.x86_64.rpm
dmapi-2.2.8-22.1.x86_64.rpm
boost-1.33.1-108.5.x86_64.rpm
dbus-1-32bit-1.0.2-59.4.x86_64.rpm
e2fsprogs-1.40.2-20.2.x86_64.rpm
aaa_base-10.3-90.2.x86_64.rpm
bzip2-1.0.4-42.2.x86_64.rpm
dbus-1-glib-0.74-25.1.x86_64.rpm
hal-0.5.9_git20070831-13.2.x86_64.rpm
audit-libs-1.5.5-13.4.x86_64.rpm
cpio-2.9-17.2.x86_64.rpm
dhcpcd-1.3.22pl4-287.2.x86_64.rpm

You can find all of them at:

http://opensuse.unixheads.org/update/10.3/rpm/x86_64/

I really want to know which one is "the chosen one" :)

Best regards,
Nenad Strainovic