Bug #58199 name_const in the having clause crashes
Submitted: 15 Nov 2010 11:59 Modified: 15 Dec 2010 1:08
Reporter: Shane Bester (Platinum Quality Contributor) Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Parser Severity:S1 (Critical)
Version:5.5.7, 5.5.8 OS:Any
Assigned to: Magne Mæhre CPU Architecture:Any
Tags: name_const, regression

[15 Nov 2010 11:59] Shane Bester
Description:
5.5.7:

mysqld.exe!Item_ref::basic_const_item()[item.h:2575]
mysqld.exe!Item_name_const::Item_name_const()[item.cc:1346]
mysqld.exe!Create_func_name_const::create()[item_create.cc:4082]
mysqld.exe!Create_func_arg2::create_func()[item_create.cc:2627]
mysqld.exe!MYSQLparse()[sql_yacc.yy:11847]
mysqld.exe!parse_sql()[sql_parse.cc:7223]
mysqld.exe!mysql_parse()[sql_parse.cc:5455]
mysqld.exe!dispatch_command()[sql_parse.cc:1032]
mysqld.exe!do_command()[sql_parse.cc:769]
mysqld.exe!do_handle_one_connection()[sql_connect.cc:745]
mysqld.exe!handle_one_connection()[sql_connect.cc:684]
mysqld.exe!pthread_start()[my_winthread.c:61]
mysqld.exe!_callthreadstartex()[threadex.c:348]
mysqld.exe!_threadstartex()[threadex.c:326]

5.1.54 didn't crash. this is a regression of some kind.

How to repeat:
drop table if exists `t`;
create table `t`(`a` int)engine=myisam;
select 1 from `t` having name_const('',`a`);
[15 Nov 2010 12:21] Peter Laursen
the `backticks` are not required to reproduce the crash

DROP TABLE IF EXISTS `t`;
CREATE TABLE `t`(`a` INT)ENGINE=MYISAM;
SELECT NAME_CONST('', 'a'); -- valid
SELECT 1 FROM `t` HAVING NAME_CONST('','a'); -- does not crash

DROP TABLE IF EXISTS `t`;
CREATE TABLE `t`(`a` INT)ENGINE=MYISAM;
SELECT NAME_CONST('', a); -- Error Code : 1210 - Incorrect arguments to NAME_CONST
SELECT 1 FROM `t` HAVING NAME_CONST('',a); -- crash
[15 Nov 2010 14:27] Valeriy Kravchuk
Verified on Mac OS X:

...
Version: '5.5.7-rc-debug'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
101115 16:25:54 - mysqld got signal 10 ;
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=8388608
read_buffer_size=131072
max_used_connections=1
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337959 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x183a600
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 = 0xb077ef34 thread_stack 0x30000
0   mysqld                              0x005c9905 my_print_stacktrace + 44
1   mysqld                              0x00105dc2 handle_segfault + 884
2   libSystem.B.dylib                   0x940472bb _sigtramp + 43
3   ???                                 0xffffffff 0x0 + 4294967295
4   mysqld                              0x0002494a _ZN15Item_name_constC1EP4ItemS1_ + 118
5   mysqld                              0x0009f9e6 _ZN22Create_func_name_const6createEP3THDP4ItemS3_ + 62
6   mysqld                              0x0009aaa4 _ZN16Create_func_arg211create_funcEP3THD19st_mysql_lex_stringP4ListI4ItemE + 198
7   mysqld                              0x0013e42d _Z10MYSQLparsePv + 89801
8   mysqld                              0x0011075f _Z9parse_sqlP3THDP12Parser_stateP19Object_creation_ctx + 217
9   mysqld                              0x00120484 _Z11mysql_parseP3THDPcjP12Parser_state + 204
10  mysqld                              0x00120f3d _Z16dispatch_command19enum_server_commandP3THDPcj + 1993
11  mysqld                              0x0012234b _Z10do_commandP3THD + 621
12  mysqld                              0x0010f9db _Z24do_handle_one_connectionP3THD + 515
13  mysqld                              0x0010facd handle_one_connection + 37
14  libSystem.B.dylib                   0x9400c095 _pthread_start + 321
15  libSystem.B.dylib                   0x9400bf52 thread_start + 34
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x18a5c10 = select 1 from `t` having name_const('',`a`)
thd->thread_id=1
thd->killed=NOT_KILLED
[17 Nov 2010 13:05] 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/124156

3348 Magne Mahre	2010-11-17
      Bug#58199 name_const in the having clause crashes
      
      NAME_CONST(..) was used wrongly in a HAVING clause, and
      should have caused a user error.  Instead, it caused a
      segmentation fault.
      
      During parsing, the value parameter to NAME_CONST was
      specified to be an uninitialized Item_ref object (it
      would be resolved later).   During the semantic analysis,
      the object is tested, and since it was not initialied,
      the server seg.faulted.
      
      The fix is to check if the object is initialized
      before testing it.  The same pattern has already been
      applied to most other methods in the Item_ref class.
      
      Bug was introduced by the optimization done as part of
      Bug#33546.
[18 Nov 2010 9:45] 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/124234

3351 Magne Mahre	2010-11-18
      Bug#58199 name_const in the having clause crashes
      
      NAME_CONST(..) was used wrongly in a HAVING clause, and
      should have caused a user error.  Instead, it caused a
      segmentation fault.
      
      During parsing, the value parameter to NAME_CONST was
      specified to be an uninitialized Item_ref object (it
      would be resolved later).   During the semantic analysis,
      the object is tested, and since it was not initialied,
      the server seg.faulted.
      
      The fix is to check if the object is initialized
      before testing it.  The same pattern has already been
      applied to most other methods in the Item_ref class.
      
      Bug was introduced by the optimization done as part of
      Bug#33546.
[18 Nov 2010 12:35] Øystein Grøvlen
One reviewer should be enough in this case.
[18 Nov 2010 13:04] 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/124246

3190 Magne Mahre	2010-11-18
      Bug#58199 name_const in the having clause crashes
            
      NAME_CONST(..) was used wrongly in a HAVING clause, and
      should have caused a user error.  Instead, it caused a
      segmentation fault.
            
      During parsing, the value parameter to NAME_CONST was
      specified to be an uninitialized Item_ref object (it
      would be resolved later).   During the semantic analysis,
      the object is tested, and since it was not initialied,
      the server seg.faulted.
            
      The fix is to check if the object is initialized
      before testing it.  The same pattern has already been
      applied to most other methods in the Item_ref class.
            
      Bug was introduced by the optimization done as part of
      Bug#33546.
[18 Nov 2010 13:06] Magne Mæhre
Pushed to mysql-5.5-runtime (rev. 3190)
[5 Dec 2010 12:43] Bugs System
Pushed into mysql-trunk 5.6.1 (revid:alexander.nozdrin@oracle.com-20101205122447-6x94l4fmslpbttxj) (version source revid:alexander.nozdrin@oracle.com-20101205122447-6x94l4fmslpbttxj) (merge vers: 5.6.1) (pib:23)
[15 Dec 2010 1:08] Paul Dubois
Noted in 5.5.8 changelog.

Use of NAME_CONST() in a HAVING clause caused a server crash.
[16 Dec 2010 22:33] Bugs System
Pushed into mysql-5.5 5.5.9 (revid:jonathan.perkin@oracle.com-20101216101358-fyzr1epq95a3yett) (version source revid:jonathan.perkin@oracle.com-20101216101358-fyzr1epq95a3yett) (merge vers: 5.5.9) (pib:24)