Bug #30273 merge tables: Can't lock file (errno: 155)
Submitted: 7 Aug 2007 14:48 Modified: 14 Jan 2008 19:05
Reporter: Shane Bester
Status: Closed
Category:Server: Merge Severity:S2 (Serious)
Version:5.0.48BK,5.1.22BK OS:Microsoft Windows (XP)
Assigned to: Ingo Strüwing Target Version:
Tags: merge, Optimize
Triage: D3 (Medium)

[7 Aug 2007 14:48] Shane Bester 
Description:
Doing some tests with optimize, flush, lock, of merge tables on windows leads to the
following errors sometimes:

query failed (1015) - Can't lock file (errno: 155): insert into m1 values
query failed (1015) - Can't lock file (errno: 155): insert into m1 values
query failed (1015) - Can't lock file (errno: 155): insert into m1 values
query failed (1015) - Can't lock file (errno: 155): insert into m1 values
query failed (1015) - Can't lock file (errno: 155): insert into m1 values
query failed (1015) - Can't lock file (errno: 155): insert into m1 values
query failed (1015) - Can't lock file (errno: 155): insert into m1 values
query failed (1015) - Can't lock file (errno: 155): insert into m1 values
query failed (1015) - Can't lock file (errno: 155): insert into m1 values
query failed (1015) - Can't lock file (errno: 155): insert into m1 values

Sometimes a crash occurs on debug binary. Will upload stack traces in file.

I'm not sure about meaning of this error message either. MSDN says:
ERROR_TOO_MANY_TCBS 155 Cannot create another thread. 

How to repeat:
uploading testcase later.  Seems to be windows specific.

Suggested fix:
Maybe this will be fixed with bug #26379 I just wanted to make sure we have another
testcase for a slightly different problem (new error message).
[7 Aug 2007 17:11] Shane Bester 
testcase. point to a windows host, and run it.

Attachment: bug30273.c (text/plain), 5.99 KiB.
[7 Aug 2007 17:13] Shane Bester 
sbester@www:~> gcc bug30273.c -Wall -g -o bug30273
-L/home/sbester/server/5.0/mysql-5.0.48-linux-i686/lib
-I/home/sbester/server/5.0/mysql-5.0.48-linux-i686/include   -lmysqlclient_r -lz
-lpthread

sbester@www:~> ./bug30273 
running initializations..
about to spawn 5 threads
.....
completed spawning new database worker threads
testcase is now running, so watch for error output
query failed 'insert into m1 values ()' : 1015 (Can't lock file (errno: 155))
query failed 'insert into m1 values ()' : 1015 (Can't lock file (errno: 155))
query failed 'insert into m1 values ()' : 1015 (Can't lock file (errno: 155))
query failed 'insert into m1 values ()' : 1015 (Can't lock file (errno: 155))
query failed 'insert into m1 values ()' : 1015 (Can't lock file (errno: 155))
[2 Dec 2007 20:36] 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/39075

ChangeSet@1.2623, 2007-12-02 20:36:46+01:00, istruewing@stella.local +1 -0
  Bug#30273 - merge tables: Can't lock file (errno: 155)
  
  The patch for Bug#26379 (Combination of FLUSH TABLE and
  REPAIR TABLE corrupts a MERGE table) fixed this bug too.
  However it revealed a new bug that crashed the server.
  
  Flushing a merge table at the moment when it is between open
  and attach of children crashed the server.
  
  The flushing thread wants to abort locks on the flushed table.
  It calls ha_myisammrg::lock_count() and ha_myisammrg::store_lock()
  on the TABLE object of the other thread.
  
  Changed ha_myisammrg::lock_count() and ha_myisammrg::store_lock()
  to accept non-attached children.
  
  The test case follows in another changeset. It requires some
  effort to make the problem repeatable.
[4 Dec 2007 12:23] 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/39192

ChangeSet@1.2624, 2007-12-04 12:22:46+01:00, istruewing@stella.local +7 -0
  Bug#30273 - merge tables: Can't lock file (errno: 155)
  
  This changeset contains the test for the bug fix.
  
  The bug was not repeatable with the test suite.
  The flush had to happen while the other thread was between
  opening the merge table and attaching the children. This is a
  very short time interval.
  
  To make such race conditions repeatable, the changeset contains
  a new facility. It is only contained in a debug server.
  The "test synchronization" facility allows to place
  synchronization points in the code, where signals can be sent
  and/or waited for. This is controlled by user variables.
[5 Dec 2007 11:16] Dmitri Lenev 
Discussion on IRC revealed that even with this patch there might be a possibility that
thread doing ha_myisammrg::extra(HA_EXTRA_ATTACH_CHILDREN) will sneak in between
ha_myisammrg::lock_count() and ha_myisammrg::store_lock() causing
problems for mysql_lock_abort_for_thread() function which has called them.
This issue requires additional investigation and possibly new patch so I am returning
this bug back to "In progress".
[5 Dec 2007 16:37] 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/39321

ChangeSet@1.2623, 2007-12-05 16:36:52+01:00, istruewing@stella.local +2 -0
  Bug#30273 - merge tables: Can't lock file (errno: 155)
  
  The patch for Bug#26379 (Combination of FLUSH TABLE and
  REPAIR TABLE corrupts a MERGE table) fixed this bug too.
  However it revealed a new bug that crashed the server.
  
  Flushing a merge table at the moment when it is between open
  and attach of children crashed the server.
  
  The flushing thread wants to abort locks on the flushed table.
  It calls ha_myisammrg::lock_count() and ha_myisammrg::store_lock()
  on the TABLE object of the other thread.
  
  Changed ha_myisammrg::lock_count() and ha_myisammrg::store_lock()
  to accept non-attached children.
  
  The test case follows in another changeset. It requires some
  effort to make the problem repeatable.
[10 Dec 2007 13:12] 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/39643

ChangeSet@1.2623, 2007-12-10 13:10:42+01:00, istruewing@stella.local +4 -0
  Bug#30273 - merge tables: Can't lock file (errno: 155)
  
  The patch for Bug 26379 (Combination of FLUSH TABLE and
  REPAIR TABLE corrupts a MERGE table) fixed this bug too.
  However it revealed a new bug that crashed the server.
  
  Flushing a merge table at the moment when it is between open
  and attach of children crashed the server.
  
  The flushing thread wants to abort locks on the flushed table.
  It calls ha_myisammrg::lock_count() and ha_myisammrg::store_lock()
  on the TABLE object of the other thread.
  
  Changed ha_myisammrg::lock_count() and ha_myisammrg::store_lock()
  to accept non-attached children.
  
  No test case. The test suite cannot reliably run FLUSH between
  lock_count() and store_lock() of another thread. The bug report
  contains a program that can repeat the problem with some
  probability.
[10 Dec 2007 17:33] 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/39655

ChangeSet@1.2678, 2007-12-10 17:32:46+01:00, istruewing@stella.local +5 -0
  Bug#30273 - merge tables: Can't lock file (errno: 155)
  
  The patch for Bug 26379 (Combination of FLUSH TABLE and
  REPAIR TABLE corrupts a MERGE table) fixed this bug too.
  However it revealed a new bug that crashed the server.
  
  Flushing a merge table at the moment when it is between open
  and attach of children crashed the server.
  
  The flushing thread wants to abort locks on the flushed table.
  It calls ha_myisammrg::lock_count() and ha_myisammrg::store_lock()
  on the TABLE object of the other thread.
  
  Changed ha_myisammrg::lock_count() and ha_myisammrg::store_lock()
  to accept non-attached children.
  
  No test case. The test suite cannot reliably run FLUSH between
  lock_count() and store_lock() of another thread. The bug report
  contains a program that can repeat the problem with some
  probability.
[10 Dec 2007 19:52] 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/39670

ChangeSet@1.2678, 2007-12-10 19:52:12+01:00, istruewing@stella.local +5 -0
  Bug#30273 - merge tables: Can't lock file (errno: 155)
  
  The patch for Bug 26379 (Combination of FLUSH TABLE and
  REPAIR TABLE corrupts a MERGE table) fixed this bug too.
  However it revealed a new bug that crashed the server.
  
  Flushing a merge table at the moment when it is between open
  and attach of children crashed the server.
  
  The flushing thread wants to abort locks on the flushed table.
  It calls ha_myisammrg::lock_count() and ha_myisammrg::store_lock()
  on the TABLE object of the other thread.
  
  Changed ha_myisammrg::lock_count() and ha_myisammrg::store_lock()
  to accept non-attached children.
  
  No test case. The test suite cannot reliably run FLUSH between
  lock_count() and store_lock() of another thread. The bug report
  contains a program that can repeat the problem with some
  probability.
[11 Dec 2007 15:19] 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/39712

ChangeSet@1.2678, 2007-12-11 15:19:14+01:00, istruewing@stella.local +7 -0
  Bug#30273 - merge tables: Can't lock file (errno: 155)
  
  The patch for Bug 26379 (Combination of FLUSH TABLE and
  REPAIR TABLE corrupts a MERGE table) fixed this bug too.
  However it revealed a new bug that crashed the server.
  
  Flushing a merge table at the moment when it is between open
  and attach of children crashed the server.
  
  The flushing thread wants to abort locks on the flushed table.
  It calls ha_myisammrg::lock_count() and ha_myisammrg::store_lock()
  on the TABLE object of the other thread.
  
  Changed ha_myisammrg::lock_count() and ha_myisammrg::store_lock()
  to accept non-attached children. ha_myisammrg::lock_count() returns
  the number of MyISAM tables in the MERGE table so that the memory
  allocation done by get_lock_data() is done correctly, even if the
  children become attached before ha_myisammrg::store_lock() is
  called. ha_myisammrg::store_lock() will not return any lock if the
  children are not attached.
  
  This is however a change in the handler interface. lock_count()
  can now return a higher number than store_lock() stores locks.
  This is more safe than the reverse implementation would be.
  get_lock_data() in the SQL layer is adjusted accordingly. It sets
  MYSQL_LOCK::lock_count based on the number of locks returned by
  the handler::store_lock() calls, not based on the numbers returned
  by the handler::lock_count() calls. The latter are only used for
  allocation of memory now.
  
  No test case. The test suite cannot reliably run FLUSH between
  lock_count() and store_lock() of another thread. The bug report
  contains a program that can repeat the problem with some
  probability.
[13 Dec 2007 0:00] Bugs System 
Pushed into 6.0.5-alpha
[13 Dec 2007 0:02] Bugs System 
Pushed into 5.1.23-rc
[14 Jan 2008 19:05] Jon Stephens 
Documented bugfix in 5.1.23 and 6.0.5 changelogs. Closed.