MySQL Bugs: #30273: merge tables: Can't lock file (errno: 155)

Bug #30273	merge tables: Can't lock file (errno: 155)
Submitted:	7 Aug 2007 12:48	Modified:	14 Jan 2008 18:05
Reporter:	Shane Bester (Platinum Quality Contributor)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Merge storage engine	Severity:	S2 (Serious)
Version:	5.0.48BK,5.1.22BK	OS:	Windows (XP)
Assigned to:	Ingo Strüwing	CPU Architecture:	Any
Tags:	merge, Optimize

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).

testcase. point to a windows host, and run it.

Attachment: bug30273.c (text/plain), 5.99 KiB.

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))

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.

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.

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".

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.

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.

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.

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.

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.

Pushed into 6.0.5-alpha

Pushed into 5.1.23-rc

Documented bugfix in 5.1.23 and 6.0.5 changelogs. Closed.