Bug 433196 - MySQL crashes when doing signed/unsigned comparison
MySQL crashes when doing signed/unsigned comparison
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: mysql (Show other bugs)
5.0
All Linux
low Severity high
: rc
: ---
Assigned To: Tom Lane
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-17 07:58 EST by Benjamin Morel
Modified: 2013-07-02 23:17 EDT (History)
2 users (show)

See Also:
Fixed In Version: 5.0.45-7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-25 21:06:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Benjamin Morel 2008-02-17 07:58:59 EST
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 09:09:51 EST
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-17 19:29:21 EST
Thank you, but this bug dates back from ... 2006 !?
Comment 3 Tom Lane 2008-05-25 21:06:36 EDT
Fixed in RHEL5.2 update.

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