Bug 433196 - MySQL crashes when doing signed/unsigned comparison
Summary: MySQL crashes when doing signed/unsigned comparison
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: mysql
Version: 5.0
Hardware: All
OS: Linux
low
high
Target Milestone: rc
: ---
Assignee: Tom Lane
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-02-17 12:58 UTC by Benjamin Morel
Modified: 2013-07-03 03:17 UTC (History)
2 users (show)

Fixed In Version: 5.0.45-7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-26 01:06:36 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Benjamin Morel 2008-02-17 12:58:59 UTC
Description of problem:
MySQL seems to crash if we request it to compare a signed value with an 
unsigned one.

Version-Release number of selected component (if applicable):
mysql-server-5.0.22-2.2.el5_1.1

How reproducible:
CREATE TABLE crash (ID INT(10) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY);
INSERT INTO crash VALUES(),();
SELECT COUNT(*) FROM crash  WHERE ID NOT IN(-1,1);
  
Actual results:
ERROR 2013 (HY000): Lost connection to MySQL server during query

Expected results:
+----------+
| COUNT(*) |
+----------+
|        1 |
+----------+

Additional info:

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=402653184
read_buffer_size=2093056
max_used_connections=1
max_connections=500
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 
2439212 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x9077230
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=0x91041f88, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81745b3
0x59e420
(nil)
0x82123a9
0x82141ac
0x81cd660
0x81ce410
0x81d4d4e
0x81d5613
0x818abae
0x8190119
0x81906c1
0x81918bc
0x819237c
0x79145b
0x6e924e
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 0x90a1430 = SELECT COUNT(*) FROM crash  WHERE ID NOT IN(-1,1)
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

Comment 1 Tom Lane 2008-02-17 14:09:51 UTC
Already reported upstream as http://bugs.mysql.com/bug.php?id=19618.  Seems to be fixed in 5.0.45 
which we expect to push out in the RHEL 5.2 scheduled update.

Comment 2 Benjamin Morel 2008-02-18 00:29:21 UTC
Thank you, but this bug dates back from ... 2006 !?

Comment 3 Tom Lane 2008-05-26 01:06:36 UTC
Fixed in RHEL5.2 update.


Note You need to log in before you can comment on or make changes to this bug.