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.

mysql-test/r/func_misc.result

@@ -375,4 +375,10 @@ GREATEST(a, (SELECT b FROM t1 LIMIT 1))
 3
 1
 DROP TABLE t1;
-End of 5.1 tests
+#
+# Bug #58199: name_const in the having clause crashes
+#
+CREATE TABLE t1 (a INT);
+SELECT 1 from t1 HAVING NAME_CONST('', a);
+ERROR HY000: Incorrect arguments to NAME_CONST
+DROP TABLE t1;

mysql-test/t/func_misc.test

@@ -504,4 +504,15 @@ SELECT DISTINCT GREATEST(a, (SELECT b FROM t1 LIMIT 1)) FROM t1 UNION SELECT 1;
 
 DROP TABLE t1;
 
---echo End of 5.1 tests
+--echo #
+--echo # Bug #58199: name_const in the having clause crashes
+--echo #
+
+CREATE TABLE t1 (a INT);
+
+# NAME_CONST() would seg.fault when used wrongly in a HAVING clause
+--error ER_WRONG_ARGUMENTS
+SELECT 1 from t1 HAVING NAME_CONST('', a);
+
+DROP TABLE t1;
+

sql/item.h

@@ -2572,7 +2572,7 @@ class Item_ref :public Item_ident
     DBUG_ASSERT(fixed);
     return (*ref)->get_time(ltime);
   }
-  virtual bool basic_const_item() const { return (*ref)->basic_const_item(); }
+  virtual bool basic_const_item() const { return ref && (*ref)->basic_const_item(); }
   bool is_outer_field() const
   {
     DBUG_ASSERT(fixed);