Bug #38124 "general_log_file" variable silently unset when using expression
Submitted: 15 Jul 2008 10:05 Modified: 12 Nov 20:54
Reporter: Giuseppe Maxia
Status: Closed
Category:Server: Logging Severity:S2 (Serious)
Version:5.1.26 OS:Any (Mac OSX and Linux)
Assigned to: Magne Mæhre Target Version:6.0
Tags: SET, filename, logging
Triage: Triaged: D2 (Serious)

[15 Jul 2008 10:05] Giuseppe Maxia
Description:
The "general_log_file" variable hold the name of the general log file.
By default, it is "`hostname`.log", unless the PID file was named (Bug#33693).
When you set this variable with a literal, the assignment succeeds. If the name is the
result of an expression, the assignment fails silently.

What's worse, the file name is set to the default name, not the latest one that was
assigned. For example:

mysql> show variables like 'gen%';
+------------------+---------------------------------+
| Variable_name    | Value                           |
+------------------+---------------------------------+
| general_log      | OFF                             | 
| general_log_file | /usr/local/mysql/data/gmac3.log | 
+------------------+---------------------------------+
2 rows in set (0.00 sec)

# successful assignment
mysql> set global general_log_file='general.log';
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'gen%';
+------------------+-------------+
| Variable_name    | Value       |
+------------------+-------------+
| general_log      | OFF         | 
| general_log_file | general.log | 
+------------------+-------------+
2 rows in set (0.00 sec)

#unsuccessful assignment
mysql> set global general_log_file=concat('general.log');
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'gen%';
+------------------+---------------------------------+
| Variable_name    | Value                           |
+------------------+---------------------------------+
| general_log      | OFF                             | 
| general_log_file | /usr/local/mysql/data/gmac3.log | 
+------------------+---------------------------------+
2 rows in set (0.00 sec)

Notice that you can use prepared statements to set a global variable.

set @g = 'general.log';
set @q= concat('set global general_log_file="', @g, '"');

prepare q from @q;
Query OK, 0 rows affected (0.00 sec)
Statement prepared

execute q;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'gen%';
+------------------+-------------+
| Variable_name    | Value       |
+------------------+-------------+
| general_log      | OFF         | 
| general_log_file | general.log | 
+------------------+-------------+

How to repeat:
show variables like 'gen%';
set global general_log_file='general.log';
show variables like 'gen%';
set global general_log_file=concat('general.log');
show variables like 'gen%';

Suggested fix:
none.
[15 Jul 2008 16:30] Susanne Ebrecht
Verified as described
[15 Jul 2008 20:27] Giuseppe Maxia
Not all expressions fail, though. The following ones succeed in the assignment.

set global general_log_file=(select "A");
Query OK, 0 rows affected (0.11 sec)

show variables like 'gen%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| general_log      | ON    | 
| general_log_file | A     | 
+------------------+-------+

set global general_log_file=convert(concat("B") using ascii);
Query OK, 0 rows affected (0.10 sec)

show variables like 'gen%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| general_log      | ON    | 
| general_log_file | B     | 
+------------------+-------+

set @a = 'AAA';
Query OK, 0 rows affected (0.00 sec)

set global general_log_file = CONVERT( @a using ascii);
Query OK, 0 rows affected (0.11 sec)

show variables like 'gen%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| general_log      | ON    | 
| general_log_file | AAA   | 
+------------------+-------+

(Thanks to Philip Stoev for the hint)
[16 Jul 2008 15:54] Omer BarNir
Partial workaround: Write out the expression value
[12 Sep 2008 3:39] 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/53907

2695 He Zhenxing	2008-09-12 [merge]
      Auto merge
[12 Sep 2008 3:44] 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/53908

2695 He Zhenxing	2008-09-12 [merge]
      Auto merge
[23 Sep 2008 13:13] 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/54481

2694 He Zhenxing	2008-09-22 [merge]
      Auto Merge
[30 Jan 14:31] Bugs System
Pushed into 6.0.10-alpha (revid:luis.soares@sun.com-20090129165607-wiskabxm948yx463)
(version source revid:luis.soares@sun.com-20090129163120-e2ntks4wgpqde6zt) (merge vers:
6.0.10-alpha) (pib:6)
[30 Jan 16:10] Bugs System
Pushed into 5.1.32 (revid:luis.soares@sun.com-20090129165946-d6jnnfqfokuzr09y) (version
source revid:hezx@mysql.com-20080929053642-b2mfvfhzisrzj274) (merge vers: 5.1.30) (pib:6)
[17 Feb 15:57] Bugs System
Pushed into 5.1.32-ndb-6.3.23 (revid:tomas.ulin@sun.com-20090217131017-6u8qz1edkjfiobef)
(version source revid:tomas.ulin@sun.com-20090203133556-9rclp06ol19bmzs4) (merge vers:
5.1.32-ndb-6.3.22) (pib:6)
[17 Feb 17:45] Bugs System
Pushed into 5.1.32-ndb-6.4.3 (revid:tomas.ulin@sun.com-20090217134419-5ha6xg4dpedrbmau)
(version source revid:tomas.ulin@sun.com-20090203133556-9rclp06ol19bmzs4) (merge vers:
5.1.32-ndb-6.3.22) (pib:6)
[17 Feb 19:21] Bugs System
Pushed into 5.1.32-ndb-6.2.17 (revid:tomas.ulin@sun.com-20090217134216-5699eq74ws4oxa0j)
(version source revid:tomas.ulin@sun.com-20090201210519-vehobc4sy3g9s38e) (merge vers:
5.1.32-ndb-6.2.17) (pib:6)
[25 Mar 23:28] 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/70450

2749 Magne Mahre	2009-03-25
      Bug #38124 "general_log_file" variable silently unset when using expression
      
      When assigning the new string value to the variable, the
      Item::str_value member was used.  This is not according to
      the protocol.  str_value is an internal member used for
      temporary assignments, and is not consistently set for all
      string operations.  It is set for constant strings, so it would
      work in these cases, but not for string functions (concat,
      substr, etc.)
      
      The correct approach is to use Item::val_str(..) to evaluate
      and retrieve the string.
     @ mysql-test/t/log_state.test
        The test hacks introduced to counter the effects of this bug has been removed.
[30 Mar 20:40] 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/70841

2758 Magne Mahre	2009-03-30
       Bug #38124 "general_log_file" variable silently unset when using expression
            
      When assigning the new string value to the variable, the
      Item::str_value member was used.  This is not according to
      the protocol.  str_value is an internal member used for
      temporary assignments, and is not consistently set for all
      string operations.  It is set for constant strings, so it would
      work in these cases, but not for string functions (concat,
      substr, etc.)
            
      The correct approach is to use Item::val_str(..) to evaluate
      and retrieve the string.
     @ mysql-test/t/log_state.test
        The test hacks introduced to counter the effects of this bug has been removed.
[31 Mar 18:49] 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/70931

2759 Magne Mahre	2009-03-31
      Bug #38124 "general_log_file" variable silently unset when using expression
                  
      When assigning the new string value to the variable, the
      Item::str_value member was used.  This is not according to
      the protocol.  str_value is an internal member used for
      temporary assignments, and is not consistently set for all
      string operations.  It is set for constant strings, so it would
      work in these cases, but not for string functions (concat,
      substr, etc.)
                  
      The correct approach is to use Item::val_str(..) to evaluate
      and retrieve the string.
[16 May 10:41] Bugs System
Pushed into 6.0.12-alpha (revid:alik@sun.com-20090516083402-0avycdy7w6dnn0tv) (version
source revid:serg@mysql.com-20090512164111-jz224w5781lhe7wd) (merge vers: 6.0.12-alpha)
(pib:6)
[19 May 2:48] Paul DuBois
Noted in 6.0.12 changelog.

Setting the general_log_file or slow_query_log_file system variable
to a non-constant expression caused the variable to become unset.
[15 Oct 11:11] 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/86908

2924 Magne Mahre	2009-10-15
      Bug #38124 "general_log_file" variable silently unset when using expression
                        
      When assigning the new string value to the variable, the
      Item::str_value member was used.  This is not according to
      the protocol.  str_value is an internal member used for
      temporary assignments, and is not consistently set for all
      string operations.  It is set for constant strings, so it would
      work in these cases, but not for string functions (concat,
      substr, etc.)
                        
      The correct approach is to use Item::val_str(..) to evaluate
      and retrieve the string.
      
      Backport from 6.0-codebase
      
      6.0-codebase revno: 2617.31.17
[15 Oct 11:12] Magne Mæhre
Backported to 5.5.0
[15 Oct 13:39] 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/86943

2926 Magne Mahre	2009-10-15
      Bug #38124  (clean-up patch)
      
      The fix for Bug #38124 introuced a bug. If the value given 
      for a set_var exceeded the length of the temporary buffer,
      we would read behind the end of the buffer.  Using 
      c_ptr_safe(), instead of c_ptr(), ensures that we won't
      read beyond the buffer limit
      
      mysql-6.0-codebase revid: 2617.44.1
[15 Oct 21:29] Paul DuBois
Noted in 5.5.0 changelog.
[3 Nov 8:18] Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20091102151658-j9o4wgro47m5v84d) (version
source revid:alik@sun.com-20091023064702-2f8jdmny61bdl94u) (merge vers: 6.0.14-alpha)
(pib:13)
[3 Nov 16:28] Paul DuBois
Already fixed in earlier 6.0.x release.
[12 Nov 9:21] Bugs System
Pushed into 5.5.0-beta (revid:alik@sun.com-20091110093229-0bh5hix780cyeicl) (version
source revid:mikael@mysql.com-20091103113702-p61dlwc6ml6fxg18) (merge vers: 5.5.0-beta)
(pib:13)