Bug #38124 "general_log_file" variable silently unset when using expression
Submitted: 15 Jul 2008 8:05 Modified: 12 Nov 2009 19:54
Reporter: Giuseppe Maxia Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Logging Severity:S2 (Serious)
Version:5.1.26 OS:Any (Mac OSX and Linux)
Assigned to: Magne Mæhre CPU Architecture:Any
Tags: filename, logging, SET

[15 Jul 2008 8: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 14:30] Susanne Ebrecht 
Verified as described
[15 Jul 2008 18: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 13:54] Omer Barnir 
Partial workaround: Write out the expression value
[12 Sep 2008 1: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 1: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 11: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 2009 13: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 2009 15: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 2009 14: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 2009 16: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 2009 18: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 2009 22: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 2009 18: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 2009 16: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 2009 8: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 2009 0: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 2009 9: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 2009 9:12] Magne Mæhre 
Backported to 5.5.0
[15 Oct 2009 11: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 2009 19:29] Paul DuBois 
Noted in 5.5.0 changelog.
[3 Nov 2009 7: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 2009 15:28] Paul DuBois 
Already fixed in earlier 6.0.x release.
[12 Nov 2009 8: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)
[27 Mar 2013 11:59] Laurynas Biveinis 
What is the status of this bug on 5.1? The audit trail states that the fix has been pushed into 5.1.32 yet the log_state.test in the latest 5.1 trunk still contains the workaround for the bug. It does not in the latest 5.5 trunk.

Is this bug still affecting 5.1 or is it just the testcase needing cleanup?
[28 Mar 2013 7:15] Alexander Nozdrin 
Hello,

this bug was fixed in 5.5 (so, no, it is not fixed in 5.1).

The patch you're referring to (for 5.1.32) was related, but not the bug fix.