Bug #32782 User lock hash fails to find lock
Submitted: 27 Nov 2007 17:57 Modified: 7 May 2009 14:27
Reporter: Chuck Bell Email Updates:
Status: Won't fix Impact on me:
Category:MySQL Server: Backup Severity:S3 (Non-critical)
Version:6.0 OS:Any
Assigned to: CPU Architecture:Any
Triage: Triaged: D3 (Medium)

[27 Nov 2007 17:57] Chuck Bell
The online backup tests make extensive use of user locks. We have implemented a macro named BACKUP_BREAKPOINT (see ./sql/backup/debug.h) that allows us to insert our user locks via the code. 

While this works great for all of our tests and we never encountered a problem, it wasn't until we merged with mysql-6.0 that we discovered the hash does not correctly identify user locks issued by the normal method (get_lock()). 

The problem was seen during PB when the following tests failed:

kill trigger-trans binlog_stm_mix_innodb_myisam rpl_row_sp003 mysql events_bugs

These tests failed with various issues related to missing or incorrect return results from release_lock().

How to repeat:
Modify the ./sql/backup/debug.h code to change the line in the BACKUP_BREAKPOINT macro from:




Then run the tests with:

./mysql-test-run.pl  kill trigger-trans binlog_stm_mix_innodb_myisam rpl_row_sp003 mysql events_bugs --mysqld=--binlog-format=row --force

Suggested fix:
I could not locate the exact cause, but it seems the cache is "loosing" user locks along the way. I checked all of the returns from the hash functions for out of memory problems but none of those occurred. Also, I tried adjusting the size of the hash but that did not solve the problem either. The best test to use in debug is trigger-trans as it is the easiest to see the problem.
[4 Dec 2007 17:48] Chuck Bell
Corrected status to verified.
[19 Feb 2009 19:01] 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:


2754 Horst Hunger	2009-02-19
      2. fix for bug#39484: I resetted the timeout values of get_lock as they have no influence on the actual bug. Due to bug#32782 I added NULL as value to the release_lock as being successful.
      I also replaced the first 2 "sleep 1" by wait conditions. the last 2 sleeps have not been replaced as I have not found a proper condition leading to deterministic results. All is described in comments.
[7 May 2009 14:27] Chuck Bell
The DBUG_SYNC_POINT code is no longer used therefore this bug is a non-issue. The DBUG_SYNC_POINT code was replaced with the (relatively) new DEBUG_SYNC macro in debug_sync.h.