MySQL Bugs: #16328: Crash with simple SELECT 'a';

Bug #16328	Crash with simple SELECT 'a';
Submitted:	10 Jan 2006 9:51	Modified:	17 Jan 2006 15:03
Reporter:	Alexander Keremidarski	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server	Severity:	S1 (Critical)
Version:	4.1.17-BK	OS:	Linux (Linux FC1, FC4)
Assigned to:	Evgeny Potemkin	CPU Architecture:	Any

Description:
The subject says it all.
Unfortunately I can't get backtrace for some weird reason.

How to repeat:
Compile 4.1 from bk tree
ChangeSet@1.2471.1.1, 2006-01-09 10:57:28+01:00, msvensson@devsrv-b.mysql.com

with BUILD/complie-pentium-debug-max

and run:

SELECT 'a';

mysqld crashes immediately,

There is no crash on 4.1.16-1 standard RPM on FC1:

[root@Fedora tmp]# 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 to server version: 4.1.16-standard

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

mysql> select 'a';
+---+
| a |
+---+
| a |
+---+
1 row in set (0.00 sec)

Verified just as described on 4.1.17-BK ChangeSet@1.2471.1.1, 2006-01-09 10:57:28+01:00 on Linux FC1 built using ./configure --prefix=/home/openxs/dbs/4.1 --with-extra-charsets=all --with-readline. In the error log I've got:

Version: '4.1.17'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
mysqld got signal 8;
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=8388600
read_buffer_size=131072
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 = 225791
 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0xa7133c0
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=0xb97d0a2c, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81227fd
0x64ef18
0xa719c68
0x81392b7
0x81330a1
0x8132d72
0x813256d
0x64879c
0x49527a
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 0xa74b2e8 = select 'a'
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
060110 14:22:01  mysqld restarted
060110 14:22:02  InnoDB: Started; log sequence number 0 2028688
/home/openxs/dbs/4.1/libexec/mysqld: ready for connections.
Version: '4.1.17'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution

Stack trace resolved to the following:

0x81227fd handle_segfault + 565
0x64ef18 (?)
0xa719c68 _end + 35963444
0x81392b7 _Z11mysql_parseP3THDPcj + 83
0x81330a1 _Z16dispatch_command19enum_server_commandP3THDPcj + 753
0x8132d72 _Z10do_commandP3THD + 122
0x813256d handle_one_connection + 789
0x64879c (?)
0x49527a (?)

Works OK in 4.1.18-BK (ChangeSet@1.2475, 2006-01-17 12:55:30+01:00) on the same FC1:

[openxs@Fedora 4.1]$ bin/mysql -uroot
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.1.18

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

mysql> select 'a';
+---+
| a |
+---+
| a |
+---+
1 row in set (0.00 sec)

mysql> select 'dog' <> 'DOG';
+----------------+
| 'dog' <> 'DOG' |
+----------------+
|              0 |
+----------------+
1 row in set (0.00 sec)

So, looks like 'Not a bug' anymore...

Can't repeat on latest 4.1.17-BK