MySQL Bugs: #45034: mysqld segfaults on simple select

Bug #45034	mysqld segfaults on simple select
Submitted:	22 May 2009 11:54	Modified:	22 May 2009 21:32
Reporter:	Daniel Herlitz	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S2 (Serious)
Version:	mysql-5.1-telco-6.3	OS:	Linux
Assigned to:	Assigned Account	CPU Architecture:	Any
Tags:	6.3.20

Description:
The select in question appears in a popular Java application called Quartz. The select causes a segfault in mysqld the second time it is executed (always the second time):

>echo "select version(); SET autocommit=0; SELECT TRIGGER_NAME, TRIGGER_GROUP FROM QRTZ_TRIGGERS WHERE IS_VOLATILE = '1';" | mysql --user=root T

version()
5.1.30-ndb-6.3.20-cluster-gpl-log

>echo "select version(); SET autocommit=0; SELECT TRIGGER_NAME, TRIGGER_GROUP FROM QRTZ_TRIGGERS WHERE IS_VOLATILE = '1';" | mysql --user=root T

version()
5.1.30-ndb-6.3.20-cluster-gpl-log
ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during query

mysqld log shows:

090522 13:40:26 - mysqld got signal 11 ;
key_buffer_size=134217728
read_buffer_size=1048576
max_used_connections=3
max_threads=140
threads_connected=3
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 419221 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd: 0xcc01130
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 = 0x45baef20 thread_stack 0x40000
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0xcc23f70 = SELECT TRIGGER_NAME, TRIGGER_GROUP FROM QRTZ_TRIGGERS WHERE IS_VOLATILE = '1'
thd->thread_id=8
thd->killed=NOT_KILLED

How to repeat:
Please see attached dump.sql for table definition.

>echo "create database T;" | mysql --user=root

>mysql --user=root T < dump.sql 

>echo "select version(); SET autocommit=0; SELECT TRIGGER_NAME, TRIGGER_GROUP 
FROM QRTZ_TRIGGERS WHERE IS_VOLATILE = '1';" | mysql --user=root T

>echo "select version(); SET autocommit=0; SELECT TRIGGER_NAME, TRIGGER_GROUP FROM QRTZ_TRIGGERS WHERE IS_VOLATILE = '1';" | mysql --user=root T

Suggested fix:
No idea.

Required table def and data

Attachment: dump.sql (text/x-sql), 3.34 KiB.

Hello,

I was unable to reproduce this behavior using 5.1.30-ndb-6.3.20 or 5.1.32-ndb-7.0.5 using the directions provided.

Can you also attach the my.cnf and config.ini for the cluster to this bug report?

...
mysql> /*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
Query OK, 0 rows affected (0.00 sec)

mysql> 
mysql> -- Dump completed on 2009-05-22 11:38:29
mysql> \q
Bye
matt@bouchon:~/mysql/sandbox/63$ echo "select version(); SET autocommit=0; SELECT TRIGGER_NAME, TRIGGER_GROUP 
FROM QRTZ_TRIGGERS WHERE IS_VOLATILE = '1';" | mysql -S /tmp/mysql63.sock --user=root test
version()
5.1.30-ndb-6.3.20-cluster-gpl-log
matt@bouchon:~/mysql/sandbox/63$ echo "select version(); SET autocommit=0; SELECT TRIGGER_NAME, TRIGGER_GROUP 
FROM QRTZ_TRIGGERS WHERE IS_VOLATILE = '1';" | mysql -S /tmp/mysql63.sock --user=root test
version()
5.1.30-ndb-6.3.20-cluster-gpl-log
matt@bouchon:~/mysql/sandbox/63$ echo "select version(); SET autocommit=0; SELECT TRIGGER_NAME, TRIGGER_GROUP 
FROM QRTZ_TRIGGERS WHERE IS_VOLATILE = '1';" | mysql -S /tmp/mysql63.sock --user=root test

my.cnf

Attachment: my.cnf (application/octet-stream, text), 704 bytes.

config.ini

Attachment: config.ini (application/octet-stream, text), 631 bytes.

If I set query_cache_size to 0 the problem disappears. With any value > 0 crash occurs every second time the query is executed.

Upgrading to 6.3.24 solves the problem. So that is what we will do. Thanks.

Confirmed on 6.3.20 and confirmed fixed in 7.0.5

Likely duplicate of Bug #42419