| Bug #48739 | MySQL crashes on specific INTERVAL in select query | ||
|---|---|---|---|
| Submitted: | 12 Nov 2009 18:25 | Modified: | 18 Jun 2010 1:44 |
| Reporter: | Vitaly Galushkin | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: General | Severity: | S2 (Serious) |
| Version: | 5.0/5.1.34 and above | OS: | Linux (SLES-10 x86_64 SP2) |
| Assigned to: | Christopher Powers | CPU Architecture: | Any |
| Tags: | crash, date_add interval, get_interval_value, Signal 11 | ||
[12 Nov 2009 19:00]
Valeriy Kravchuk
I can not repeat this with recent 5.1.42 and 5.0.88 from bzr (debug binaries) on Mac OS X:
77-52-7-73:5.0 openxs$ 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.88-debug Source distribution
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> SELECT DATE_ADD('2009-12-31 23:59:59.000000', INTERVAL '1.9999999' SECOND_MICROSECOND)
-> ;
+---------------------------------------------------------------------------------+
| DATE_ADD('2009-12-31 23:59:59.000000', INTERVAL '1.9999999' SECOND_MICROSECOND) |
+---------------------------------------------------------------------------------+
| 2010-01-01 00:00:09.999999 |
+---------------------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> exit
...
77-52-7-73:5.1 openxs$ 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.1.42-debug Source distribution
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> SELECT DATE_ADD('2009-12-31 23:59:59.000000', INTERVAL '1.9999999' SECOND_MICROSECOND);
+---------------------------------------------------------------------------------+
| DATE_ADD('2009-12-31 23:59:59.000000', INTERVAL '1.9999999' SECOND_MICROSECOND) |
+---------------------------------------------------------------------------------+
| 2010-01-01 00:00:09.999999 |
+---------------------------------------------------------------------------------+
1 row in set (0.00 sec)
[12 Nov 2009 19:42]
Peter Laursen
I tried:
SELECT VERSION();
-- 5.1.36-rs-log (on RHEL5 Linux - I think server slightly patched by Rackspace hosting)
SELECT DATE_ADD('2009-12-31 23:59:59.000000', INTERVAL '1.9999999' SECOND_MICROSECOND);
-- Error Code : 2013
-- Lost connection to MySQL server during query
SELECT 1; -- success - but obviously server was restarted automatically by the management system on the hosting what
SHOW GLOBAL STATUS LIKE 'uptime%';
.. tells! uptime is few seconds!
-- another server
SELECT VERSION();
-- 5.1.40-community (local 64 bit for Windows)
SELECT DATE_ADD('2009-12-31 23:59:59.000000', INTERVAL '1.9999999' SECOND_MICROSECOND);
-- returns "2010-01-01 00:00:09.999999"
so looks like some issue is or was there.
[12 Nov 2009 21:53]
MySQL Verification Team
miguel@quetzal3:~$ dbs/5.1/libexec/mysqld
091112 19:02:58 [Note] Plugin 'FEDERATED' is disabled.
091112 19:02:58 [Note] Plugin 'ndbcluster' is disabled.
091112 19:02:58 InnoDB: Started; log sequence number 0 45972
091112 19:02:58 [Note] Event Scheduler: Loaded 0 events
091112 19:02:58 [Note] dbs/5.1/libexec/mysqld: ready for connections.
Version: '5.1.42-debug' socket: '/tmp/mysql.sock' port: 3306 Source distribution
091112 19:52:56 - 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=8384512
read_buffer_size=131072
max_used_connections=1
max_threads=151
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338308 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd: 0x1e48778
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x7fac6b9800e8 thread_stack 0x40000
dbs/5.1/libexec/mysqld(my_print_stacktrace+0x35)[0xb6823b]
dbs/5.1/libexec/mysqld(handle_segfault+0x288)[0x6c3d10]
/lib/libpthread.so.0[0x7fac6fd36190]
dbs/5.1/libexec/mysqld[0x65037a]
dbs/5.1/libexec/mysqld(_Z18get_interval_valueP4Item13interval_typeP6StringP8INTERVAL+0x6d6)[0x651b36]
dbs/5.1/libexec/mysqld(_ZN22Item_date_add_interval8get_dateEP13st_mysql_timej+0x86)[0x65371e]
dbs/5.1/libexec/mysqld(_ZN22Item_date_add_interval7val_strEP6String+0x4d)[0x653839]
dbs/5.1/libexec/mysqld(_ZN4Item4sendEP8ProtocolP6String+0x88)[0x5ee970]
dbs/5.1/libexec/mysqld(_ZN11select_send9send_dataER4ListI4ItemE+0x16b)[0x6a976b]
dbs/5.1/libexec/mysqld(_ZN4JOIN4execEv+0x4d0)[0x748a68]
dbs/5.1/libexec/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x343)[0x74b2ee]
dbs/5.1/libexec/mysqld(_Z13handle_selectP3THDP6st_lexP13select_resultm+0x1c6)[0x74354e]
dbs/5.1/libexec/mysqld[0x6df884]
dbs/5.1/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x8f4)[0x6d67c3]
dbs/5.1/libexec/mysqld(_Z11mysql_parseP3THDPKcjPS2_+0x2bf)[0x6e1d73]
dbs/5.1/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0xd2d)[0x6d4016]
dbs/5.1/libexec/mysqld(_Z10do_commandP3THD+0x27e)[0x6d2ff2]
dbs/5.1/libexec/mysqld(handle_one_connection+0x14e)[0x6d12ed]
/lib/libpthread.so.0[0x7fac6fd2da04]
/lib/libc.so.6(clone+0x6d)[0x7fac6f1bc7bd]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x1ea9278 = SELECT DATE_ADD('2009-12-31 23:59:59.000000', INTERVAL '1.9999999' SECOND_MICROSECOND)
thd->thread_id=2
thd->killed=NOT_KILLED
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.
miguel@quetzal3:~$
[12 Nov 2009 21:59]
MySQL Verification Team
Thank you for the bug report. Verified on Ubuntu 9.10 X86_64.
miguel@quetzal3:~/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.88-debug Source distribution
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> SELECT DATE_ADD('2009-12-31 23:59:59.000000', INTERVAL '1.9999999' SECOND_MICROSECOND);
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>
[12 Nov 2009 22:05]
MySQL Verification Team
I couldn't repeat on Window I will verify again with new pull on Linux:
c:\dbs>c:\dbs\5.1\bin\mysql -uroot --port=3510 --prompt="mysql 5.1 >"
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.1.42-Win X64-log Source distribution
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql 5.1 >SELECT DATE_ADD('2009-12-31 23:59:59.000000', INTERVAL '1.9999999'
-> SECOND_MICROSECOND);
+---------------------------------------------------------------------------------+
| DATE_ADD('2009-12-31 23:59:59.000000', INTERVAL '1.9999999'
SECOND_MICROSECOND) |
+---------------------------------------------------------------------------------+
| 2010-01-01 00:00:09.999999 |
+---------------------------------------------------------------------------------+
1 row in set (0.04 sec)
mysql 5.1 >
[12 Nov 2009 22:16]
MySQL Verification Team
With latest source on Linux it is repeatable:
miguel@quetzal3:~/dbs/5.1$ bin/mysql -uroot
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.1.42-debug Source distribution
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> SELECT DATE_ADD('2009-12-31 23:59:59.000000', INTERVAL '1.9999999' SECOND_MICROSECOND);
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>
[18 Nov 2009 23:35]
Christopher Powers
This is an interesting bug. The immediate problem is here:
get_interval_info(...)
{
...
if (transform_msec && i == count - 1) // microseconds always last
{
>> long msec_length= 6 - (uint) (str - start);
if (msec_length > 0)
value*= (long) log_10_int[msec_length];
}
In this case, str - start == -1, so msec_length > 0 should be false, but on some systems the negative sign is not preserved, causing a crash.
On Windows 32, Windows x64 and Linux x64, the expression
6 - (uint)(str - start)
resolves as an unsigned integer (see below). In this context, however, when the result is assigned to "long msec_length", Windows preserves the sign but Linux x64 does not.
The test succeeds on Linux x64 if the expression is changed to:
long msec_length= 6 - (int) (str - start);
Interestingly, "int" and "long" are 4-byte values on Windows x64, but they are 4- and 8-byte values, respectively, on Linux x64. Although the size of "long" can vary with respect to "int" across compilers, it is not clear why the handling of the sign was different here.
This is a subtle, compiler-specific issue. I will try to find a definitive solution, because similar issues quite likely exist elsewhere in the code.
For comparison, the following watch expressions were taken from debuggers on Windows 32, 64 and Linux x64:
==========================
Windows 32-bit
==========================
(int)msec_length -1 int
(uint)msec_length 4294967295 unsigned int
(long)msec_length -1 long
(ulong)msec_length 4294967295 unsigned long
(longlong)msec_length -1 __int64
(ulonglong)msec_length 18446744073709551615 unsigned __int64
(6 - (int)(7)) -1 int
(6 - (uint)(7)) 4294967295 unsigned int
(6 - (long)(7)) -1 long
(6 - (ulong)(7)) 4294967295 unsigned long
(6 - (longlong)(7)) -1 __int64
(6 - (ulonglong)(7)) 18446744073709551615 unsigned __int64
(int)msec_length > 0 false
(uint)msec_length > 0 true
(long)msec_length > 0 false
(ulong)msec_length > 0 true
(longlong)msec_length > 0 false
(ulonglong)msec_length > 0 true
sizeof(int) 4
sizeof(uint) 4
sizeof(long) 4
sizeof(ulong) 4
sizeof(longlong) 8
sizeof(ulonglong) 8
==========================
Windows 64-bit
==========================
(int)msec_length -1 int
(uint)msec_length 4294967295 unsigned int
(long)msec_length -1 long
(ulong)msec_length 4294967295 unsigned long
(longlong)msec_length -1 __int64
(ulonglong)msec_length 18446744073709551615 unsigned __int64
(6 - (int)(7)) -1 int
(6 - (uint)(7)) 4294967295 unsigned int
(6 - (long)(7)) -1 long
(6 - (ulong)(7)) 4294967295 unsigned long
(6 - (longlong)(7)) -1 __int64
(6 - (ulonglong)(7)) 18446744073709551615 unsigned __int64
(int)msec_length > 0 false
(uint)msec_length > 0 true
(long)msec_length > 0 false
(ulong)msec_length > 0 true
(longlong)msec_length > 0 false
(ulonglong)msec_length > 0 true
sizeof(int) 4
sizeof(uint) 4
sizeof(long) 4
sizeof(ulong) 4
sizeof(longlong) 8
sizeof(ulonglong) 8
==========================
Linx (openSuSE) 64-bit
==========================
(int)msec_length -1 int
(uint)msec_length 4294967295 unsigned int
(long)msec_length 4294967295 long
(ulong)msec_length 4294967295 unsigned long
(longlong)msec_length 4294967295 long long
(ulonglong)msec_length 4294967295 unsigned long long
(6 - (int)(7)) -1 int
(6 - (uint)(7)) 4294967295 unsigned int
(6 - (long)(7)) -1 long
(6 - (ulong)(7)) 18446744073709551615 unsigned long
(6 - (longlong)(7)) -1 long
(6 - (ulonglong)(7)) 18446744073709551615 unsigned long
(int)msec_length > 0 false
(uint)msec_length > 0 true
(long)msec_length > 0 true
(ulong)msec_length > 0 true
(longlong)msec_length > 0 true
(ulonglong)msec_length > 0 true
sizeof(int) 4
sizeof(uint) 4
sizeof(long) 8
sizeof(ulong) 8
sizeof(longlong) 8
sizeof(ulonglong) 8
[19 Nov 2009 0:34]
Christopher Powers
This is a regression introduced by the fix for Bug#29125 "Windows Server X64: so many compiler warnings". See commit http://lists.mysql.com/commits/66263.
[19 Nov 2009 22:19]
Christopher Powers
Ok, finally got to the bottom of this.
To recap, two uint casts were added to item_timefunc.cc to eliminate compiler
warnings (see above), however, a crash occurs on some x64 systems because msec_length is incorrectly interpreted as non-negative:
bool get_interval_info(...)
{
...
long msec_length= 6 - (uint)(str - start);
if (msec_length > 0)
value= (long)log_10_int[msec_length];
...
}
There are two problems using the uint cast in this way:
Issue 1: The implicit type of the operation "6 - (unit)(str - start)" is uint.
Why? Because "6" is implicitly an int and the other operand is a uint. According to the C99 standard, signed integer operands are promoted to unsigned if the other operand is also unsigned.
We know that "6" is of type int because, per the standard, a decimal's type is the smallest type, int or greater, into which the value fits.
Simply put, unit and int have the same conversion rank, so uint wins the tie.
Issue 2: On x64 systems, "long" and "int" may be different sizes.
Windows x64 uses the LLP64 data model, where int and long are 32 bits and long long is 64 bits.
Linux, OS X and Solaris are LP64, where int is 32 bits, but long and long long are 64 bits.
If the arithmetic operation returns uint, then "long msec_length" interprets (uint)0xffffffff as -1 on Windows x64 and 32-bit systems. On LP64 systems, "long msec_length" interprets (uint)0xffffffff as 42949672965.
Given the redundance and type ambiguity of "long", I suggest that all "long" declarations be disambiguated with either int or longlong.
[19 Nov 2009 22:57]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/91000 3208 Christopher Powers 2009-11-19 Bug #48739 MySQL crashes on specific INTERVAL in select query Fixed crash caused by x64 int/long incompatibility introduced in Bug #29125. @ sql/item_timefunc.cc Fixed crash caused by int/long incompatibility on x64 systems. Changed two "uint" casts and a "long" declartion to "int" in order to ensure that the integer sign is preserved. See Bug #48739 for details.
[2 Dec 2009 8:04]
Bugs System
Pushed into 5.1.42 (revid:joro@sun.com-20091202080033-mndu4sxwx19lz2zs) (version source revid:davi.arnaut@sun.com-20091125130912-d7hrln14ef7y5d7i) (merge vers: 5.1.42) (pib:13)
[16 Dec 2009 8:41]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20091216083311-xorsasf5kopjxshf) (version source revid:alik@sun.com-20091214191830-wznm8245ku8xo702) (merge vers: 6.0.14-alpha) (pib:14)
[16 Dec 2009 8:47]
Bugs System
Pushed into 5.5.0-beta (revid:alik@sun.com-20091216082430-s0gtzibcgkv4pqul) (version source revid:alexey.kopytov@sun.com-20091124083136-iqm136jm31sfdwg3) (merge vers: 5.5.0-beta) (pib:14)
[16 Dec 2009 8:54]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20091216083231-rp8ecpnvkkbhtb27) (version source revid:alik@sun.com-20091212203859-fx4rx5uab47wwuzd) (merge vers: 5.6.0-beta) (pib:14)
[10 Feb 2010 19:58]
Paul DuBois
Noted in 5.1.42, 5.5.0, 6.0.14 changelogs. Certain INTERVAL expressions could cause a crash on 64-bit systems. Setting report to Need Merge pending push to Celosia.
[24 Feb 2010 22:44]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/101395 2844 Christopher Powers 2010-02-24 Bug #48739 MySQL crashes on specific INTERVAL in select query Fixed crash caused by x64 int/long incompatibility introduced in Bug #29125. @ sql/item_timefunc.cc Fixed crash caused by int/long incompatibility on x64 systems. Changed two "uint" casts and a "long" declartion to "int" in order to ensure that the integer sign is preserved. See Bug #48739 for details.
[25 Feb 2010 15:56]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/101475 2845 Christopher Powers 2010-02-25 Bug #48739 MySQL crashes on specific INTERVAL in select query Fixed crash caused by x64 int/long incompatibility introduced in Bug #29125. @ sql/item_timefunc.cc Fixed crash caused by int/long incompatibility on x64 systems. Changed two "uint" casts and a "long" declartion to "int" in order to ensure that the integer sign is preserved. See Bug #48739 for details.
[1 Mar 2010 8:36]
Bugs System
Pushed into 5.0.91 (revid:joro@sun.com-20100301083514-xujntiv5hlavch8n) (version source revid:christopher.powers@sun.com-20100225154909-oktv3odj399b8uo8) (merge vers: 5.0.91) (pib:16)
[1 Mar 2010 8:46]
Bugs System
Pushed into 5.1.45 (revid:joro@sun.com-20100301083827-xnimmrjg6bh33o1o) (version source revid:joro@sun.com-20100226131646-kpvzk740hxbtaexn) (merge vers: 5.1.45) (pib:16)
[1 Mar 2010 17:23]
Paul DuBois
Noted in 5.0.91 changelog. Already fixed in 5.1.x.
[2 Mar 2010 14:33]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100302142746-u1gxdf5yk2bjrq3e) (version source revid:alik@sun.com-20100301095421-4cz64ibem1h2quve) (merge vers: 6.0.14-alpha) (pib:16)
[2 Mar 2010 14:38]
Bugs System
Pushed into 5.5.3-m2 (revid:alik@sun.com-20100302072233-t3uqgjzdukt1pyhe) (version source revid:alik@sun.com-20100301090215-63o2w2y16go8n53p) (merge vers: 5.5.3-m2) (pib:16)
[2 Mar 2010 14:43]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100302072432-k8xvfkgcggkwgi94) (version source revid:alik@sun.com-20100301094536-2zc4uqyy3os8san7) (pib:16)
[12 Mar 2010 14:17]
Bugs System
Pushed into 5.1.44-ndb-7.0.14 (revid:jonas@mysql.com-20100312135944-t0z8s1da2orvl66x) (version source revid:jonas@mysql.com-20100312115609-woou0te4a6s4ae9y) (merge vers: 5.1.44-ndb-7.0.14) (pib:16)
[12 Mar 2010 14:33]
Bugs System
Pushed into 5.1.44-ndb-6.2.19 (revid:jonas@mysql.com-20100312134846-tuqhd9w3tv4xgl3d) (version source revid:jonas@mysql.com-20100312060623-mx6407w2vx76h3by) (merge vers: 5.1.44-ndb-6.2.19) (pib:16)
[12 Mar 2010 14:49]
Bugs System
Pushed into 5.1.44-ndb-6.3.33 (revid:jonas@mysql.com-20100312135724-xcw8vw2lu3mijrhn) (version source revid:jonas@mysql.com-20100312103652-snkltsd197l7q2yg) (merge vers: 5.1.44-ndb-6.3.33) (pib:16)
[12 Mar 2010 16:50]
Paul DuBois
Fixed in earlier 5.1.x, 5.5.x.
[17 Jun 2010 11:52]
Bugs System
Pushed into 5.1.47-ndb-7.0.16 (revid:martin.skold@mysql.com-20100617114014-bva0dy24yyd67697) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[17 Jun 2010 12:30]
Bugs System
Pushed into 5.1.47-ndb-6.2.19 (revid:martin.skold@mysql.com-20100617115448-idrbic6gbki37h1c) (version source revid:martin.skold@mysql.com-20100609140708-52rvuyq4q500sxkq) (merge vers: 5.1.45-ndb-6.2.19) (pib:16)
[17 Jun 2010 13:17]
Bugs System
Pushed into 5.1.47-ndb-6.3.35 (revid:martin.skold@mysql.com-20100617114611-61aqbb52j752y116) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[8 Apr 2011 19:35]
MySQL Verification Team
This is not properly fixed in 5.5+ (but crashes on different testcase). I filed Oracle bug #12340997 for it.
Description: MySQL crashed on the following query: SELECT DATE_ADD('2009-12-31 23:59:59.000000', INTERVAL '1.9999999' SECOND_MICROSECOND) The problem appears when using 7 or more digits in the fractional part for the interval value. This is the trace log: 091102 8:55:19 [Note] /hostname/mysql/mysql-5.1.39-linux-x86_64-glibc23/bin/mysqld: ready for connections. Version: '5.1.39' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server (GPL) 091102 8:57:51 - 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=1073741824 read_buffer_size=4194304 max_used_connections=5 max_threads=100 threads_connected=4 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1868794 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x6779b50 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x4418d190 thread_stack 0x40000 /hostname/mysql/mysql-5.1.39-linux-x86_64-glibc23/bin/mysqld(my_print_stacktrace+0x2e)[0x8ac81e] /hostname/mysql/mysql-5.1.39-linux-x86_64-glibc23/bin/mysqld(handle_segfault+0x322)[0x5df502] /lib64/libpthread.so.0[0x2aca9bf54c00] /hostname/mysql/mysql-5.1.39-linux-x86_64-glibc23/bin/mysqld[0x580472] /hostname/mysql/mysql-5.1.39-linux-x86_64-glibc23/bin/mysqld(_Z18get_interval_valueP4Item13interval_typeP6StringP8INTERVAL+0x3b2)[0x580872] /hostname/mysql/mysql-5.1.39-linux-x86_64-glibc23/bin/mysqld(_ZN22Item_date_add_interval7val_strEP6String+0x6f)[0x5851df] /hostname/mysql/mysql-5.1.39-linux-x86_64-glibc23/bin/mysqld(_ZN4Item4sendEP8ProtocolP6String+0x3e)[0x5268de] /hostname/mysql/mysql-5.1.39-linux-x86_64-glibc23/bin/mysqld(_ZN11select_send9send_dataER4ListI4ItemE+0x10d)[0x5ccfed] /hostname/mysql/mysql-5.1.39-linux-x86_64-glibc23/bin/mysqld(_ZN4JOIN4execEv+0xb3a)[0x658a5a] /hostname/mysql/mysql-5.1.39-linux-x86_64-glibc23/bin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x124)[0x6548d4] /hostname/mysql/mysql-5.1.39-linux-x86_64-glibc23/bin/mysqld(_Z13handle_selectP3THDP6st_lexP13select_resultm+0x16c)[0x65a1cc] /hostname/mysql/mysql-5.1.39-linux-x86_64-glibc23/bin/mysqld[0x5ecbda] /hostname/mysql/mysql-5.1.39-linux-x86_64-glibc23/bin/mysqld(_Z21mysql_execute_commandP3THD+0x602)[0x5efdd2] /hostname/mysql/mysql-5.1.39-linux-x86_64-glibc23/bin/mysqld(_Z11mysql_parseP3THDPKcjPS2_+0x357)[0x5f52f7] /hostname/mysql/mysql-5.1.39-linux-x86_64-glibc23/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0xe93)[0x5f6193] /hostname/mysql/mysql-5.1.39-linux-x86_64-glibc23/bin/mysqld(_Z10do_commandP3THD+0xe6)[0x5f6a56] /hostname/mysql/mysql-5.1.39-linux-x86_64-glibc23/bin/mysqld(handle_one_connection+0x246)[0x5e93f6] /lib64/libpthread.so.0[0x2aca9bf4d143] /lib64/libc.so.6(__clone+0x6d)[0x2aca9c5c98cd] Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x67850a0 = SELECT DATE_ADD('2009-12-31 23:59:59.000000', INTERVAL '1.9999999' SECOND_MICROSECOND) thd->thread_id=26 thd->killed=NOT_KILLED 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. 091102 08:57:51 mysqld_safe Number of processes running now: 0 091102 08:57:51 mysqld_safe mysqld restarted How to repeat: Run this query against 5.1.34 or above. 5.0.86 also seems to have the same problem. SELECT DATE_ADD('2009-12-31 23:59:59.000000', INTERVAL '1.9999999' SECOND_MICROSECOND) Suggested fix: 5.1.34 sources; file sql/item_timefunc.cc After rolling back 2 following changes (5.1.33 vs 5.1.34) the mysql server no longer crashes on that SELECT query: 394c394 < frac_part= 6 - (tmp - val); --- > frac_part= 6 - (uint) (tmp - val); And 884c884 < long msec_length= 6 - (str - start); --- > long msec_length= 6 - (uint) (str - start);