Bug #28870 check that table locks are released/reset
Submitted: 4 Jun 2007 11:13 Modified: 6 Mar 2010 18:49
Reporter: Sergey Vojtovich Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Locking Severity:S2 (Serious)
Version:5.0, 5.1 and up OS:Any
Assigned to: Davi Arnaut CPU Architecture:Any

[4 Jun 2007 11:13] Sergey Vojtovich
Description:
This bug is reported by request from Ingo. We agreed that the problem described below is theoretically possible.

We need locking guru to assure that get_lock_data is followed by either unlock or reset_lock_data when it is needed. In other words we mustn't have released table object with lock type != TL_UNLOCK in a table cache, unless it is intentional.

For additional information see patch for BUG#28574.

Setting priority to P2 and severity to S2 because it may cause table corruptions or even server crash.

Also please check if it is worth to move several occurences of the sequence
reset_lock_data(sql_lock);my_free(sql_lock);sql_lock=0; to an error label.

How to repeat:
See lock.cc for get_lock_data().
[10 Jun 2007 9:11] Konstantin Osipov
Not quite get the problem from the description, but ready to help.
[13 Jun 2007 11:33] Konstantin Osipov
In a nutshell, this bug report is about the following:
 - mysql_lock_tables calls function get_lock_data
 - get_lock_data calls handler::store_lock, which updates lock_type of TABLE
 - in case when mysql_lock_tables fails later on, lock_type might be not reset back to TL_UNLOCK and the table might be returned to the table cache with wrong lock_type.
 - some branches of mysql_lock_tables are covered with reset_lock_data, which addresses specifically this problem, but not all branches. 
 - the fix for this bug is to ensure that reset_lock_data happens in all cases when get_lock_data failed and we back off, abort locks, or encounter an error in mysql_lock_tables.
[31 Aug 2007 2:02] 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/33500

ChangeSet@1.2510, 2007-08-30 23:00:33-03:00, davi@moksha.local +1 -0
  Bug#28870 check that table locks are released/reset
  
  The problem is that some mysql_lock_tables error paths are not resetting the
  tables lock type back to TL_UNLOCK. If the lock types are not reset properly,
  a table might be returned to the table cache with wrong lock_type.
  
  The proposed fix is to ensure that the tables lock type is always properly
  reset when mysql_lock_tables fails.
[7 Sep 2007 14:27] Konstantin Osipov
Sent a review by email.
[10 Sep 2007 13:29] 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/33992

ChangeSet@1.2510, 2007-09-10 10:28:32-03:00, davi@moksha.local +1 -0
  Bug#28870 check that table locks are released/reset
  
  The problem is that some mysql_lock_tables error paths are not resetting the
  tables lock type back to TL_UNLOCK. If the lock types are not reset properly,
  a table might be returned to the table cache with wrong lock_type.
  
  The proposed fix is to ensure that the tables lock type is always properly
  reset when mysql_lock_tables fails.
[10 Sep 2007 22:22] 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/34022

ChangeSet@1.2608, 2007-09-10 19:22:07-03:00, davi@moksha.local +11 -0
  Bug#28870 check that table locks are released/reset
  
  The problem is that some mysql_lock_tables error paths are not resetting the
  tables lock type back to TL_UNLOCK. If the lock types are not reset properly,
  a table might be returned to the table cache with wrong lock_type.
    
  The proposed fix is to ensure that the tables lock type is always properly
  reset when mysql_lock_tables fails. This is a incompatible change with respect
  to the process state information.
[27 Sep 2007 19:57] 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/34607

ChangeSet@1.2608, 2007-09-27 16:56:27-03:00, davi@moksha.local +4 -0
  Bug#28870 check that table locks are released/reset
    
  The problem is that some mysql_lock_tables error paths are not resetting the
  tables lock type back to TL_UNLOCK. If the lock types are not reset properly,
  a table might be returned to the table cache with wrong lock_type.
      
  The proposed fix is to ensure that the tables lock type is always properly
  reset when mysql_lock_tables fails. This is a incompatible change with respect
  to the process state information.
[19 Oct 2007 20:10] Davi Arnaut
Pushed in 5.2.6
[19 Oct 2007 20:10] Davi Arnaut
Pushed in 5.2.6
[24 Oct 2007 20:26] Konstantin Osipov
Internal change, no need for a changelog entry.
[20 Nov 2009 19:16] 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/91158

2925 Konstantin Osipov	2009-11-20
      Backport of:
      revno: 2476.784.2
      committer: davi@moksha.local
      timestamp: Thu 2007-09-27 16:56:27 -0300 
      message:
      Bug#28870 check that table locks are released/reset
          
      The problem is that some mysql_lock_tables error paths are not
      resetting the tables lock type back to TL_UNLOCK. If the lock
      types are not reset properly, a table might be returned to the
      table cache with wrong lock_type.
            
      The proposed fix is to ensure that the tables lock type is always
      properly reset when mysql_lock_tables fails. This is a
      incompatible change with respect to the process state information.
     @ sql/lock.cc
        Merge mysql_lock_tables cleanup sequence and the reset_lock_data
        function into a single function and take steps to ensure it is
        always called for each error exit path. Also remove references
        to the redundant THD::locked variable which was almost exclusively
        used by this function and the same information is already on proc_info.
     @ sql/sql_class.cc
        Remove references to the THD::locked variable.
     @ sql/sql_class.h
        Remove the THD::locked variable.
     @ sql/sql_show.cc
        Remove references to THD:locked, state_info will now default to proc_info.
[20 Nov 2009 19:28] Konstantin Osipov
Queued in next-mr-runtime (5.6)
[25 Nov 2009 13:32] Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20091124194633-yc0achgq1ioyqzng) (version source revid:alik@sun.com-20091124194633-yc0achgq1ioyqzng) (merge vers: 6.0.14-alpha) (pib:13)
[25 Nov 2009 13:33] Bugs System
Pushed into 5.6.0-beta (revid:alik@sun.com-20091124193905-3iyzegd75k4givuz) (version source revid:kostja@sun.com-20091120191550-o212devfco01602d) (merge vers: 5.6.0-beta) (pib:13)
[25 Nov 2009 14:47] Paul Dubois
No changelog entry needed.
[3 Dec 2009 20:16] Davi Arnaut
This needs to be documented as a incompatible change. It removed the "Locked" thread state.
[3 Dec 2009 20:37] Paul Dubois
Noted in 5.6.0, 6.0.14 changelogs.

The Locked thread state was equivalent to the Table lock state and
has been removed. It no longer appears in SHOW PROCESSLIST output.
[6 Mar 2010 11:05] Bugs System
Pushed into 5.5.3-m3 (revid:alik@sun.com-20100306103849-hha31z2enhh7jwt3) (version source revid:vvaintroub@mysql.com-20091125142014-7asc9sj33gzki0ym) (merge vers: 5.6.0-beta) (pib:16)
[6 Mar 2010 18:49] Paul Dubois
Moved 5.6.0 changelog entry to 5.5.3.