MySQL Bugs: #25289: repair table causes "my_seek.c:56: my

Bug #25289	repair table causes "my_seek.c:56: my_seek: Assertion `fd != -1' failed"
Submitted:	27 Dec 2006 4:17	Modified:	30 Mar 2007 19:41
Reporter:	Shane Bester (Platinum Quality Contributor)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: MyISAM storage engine	Severity:	S6 (Debug Builds)
Version:	5.0.34bk	OS:	Linux (suse 9.3 x86)
Assigned to:	Ingo Strüwing	CPU Architecture:	Any
Tags:	debug assertion, my_seek, repair table

Description:
When running many threads inserting, deleting, updating a table, and also running repair table, a debug assertion happens sometimes.

061227  4:48:49 [Note] Retrying repair of: './test/t1' with keycache
mysqld: my_seek.c:56: my_seek: Assertion `fd != -1' failed.
mysqld got signal 6;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=104857600
read_buffer_size=131072
max_used_connections=34
max_connections=100
threads_connected=32
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 319996 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x474d23e8
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xba5f8fb8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x80de00b handle_segfault + 417
0x83d339d __pthread_sighandler + 173
0x8408421 __kill + 17
0x83d0c6b __pthread_raise + 27
0x84087f4 abort + 340
0x8404210 __assert_fail + 224
0x836911a my_seek + 238
0x836e0c4 init_io_cache + 470
0x83459d5 mi_repair + 514
0x81b18ec _ZN9ha_myisam6repairEP3THDR17st_mi_check_paramb + 1070
0x81b1329 _ZN9ha_myisam6repairEP3THDP15st_ha_check_opt + 311
0x81ad157 _ZN7handler9ha_repairEP3THDP15st_ha_check_opt + 35
0x81c68ab _Z17mysql_admin_tableP3THDP13st_table_listP15st_ha_check_optPKc13thr_lock_typebbjPFiS0_S2_S4_EM7handlerFiS0_S4_EPFiS0_S2_E + 2911
0x81c7426 _Z18mysql_repair_tableP3THDP13st_table_listP15st_ha_check_opt + 200
0x80f6c3a _Z21mysql_execute_commandP3THD + 8244
0x80fd568 _Z11mysql_parseP3THDPcj + 380
0x80f3508 _Z16dispatch_command19enum_server_commandP3THDPcj + 1940
0x80f2d69 _Z10do_commandP3THD + 523
0x80f1f0b handle_one_connection + 909
0x83ce271 pthread_start_thread + 225
0x8428d5a __clone + 106
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do 
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8cd8b48 = repair table `t1`
thd->thread_id=242
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

How to repeat:
Will upload a standalone testcase later.

Suggested fix:
don't pass -1 as a file descriptor.

also see related bug #23010

I found out that this is probably the same bug as
http://bugs.mysql.com/bug.php?id=25433

The debug binary crashes with assertion here.
In bug #25433, I used release binaries, which didn't crash,
but instead reported corruption in the tables.

Hence the same testcase1.c that causes corruption in bug #25433
will reproduce this bug report's crash in a debug binary.

Marking as duplicate of #25433.

Server crash verified on 5.1.17, using testcase1.c from bug #25433.

The false assertion in my_seek() has nothing to do with a similar bug that was fixed some time ago. (I believed so initially.)

The problem is that we try to repeat a failed repair under some circumstances. We did not take into account that the first repair could fail so that the table is not open any more (fd == -1).

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/21589

ChangeSet@1.2608, 2007-03-09 12:51:32+01:00, istruewing@chilla.local +1 -0
  Bug#25289 - repair table causes "my_seek.c:56:
              my_seek: Assertion `fd != -1' failed"
  
  In difficult repair situations the server could crash.
  Under some circumstances the server retries a repair
  with more elaborate options. But it did not check if
  the first repair failed so badly that a second attempt
  must not be tried.
  
  This could happen when a new data file has been created
  but it was not possible to open it. In this case the
  repair leaves behind a table with closed data file.
  This must not be used for another repair attempt.
  
  We do now detect the closed data file and do not try
  another repair attempt in this situation.
  
  No test case. The required table corruption can not be
  repeated easily. There is a test program attached to
  bug 25433.

Other places where repair is retried may be affected too.

The automatic of the bug database is broken again.

  http://lists.mysql.com/commits/21620

ChangeSet@1.2608, 2007-03-09 16:07:25+01:00, istruewing@chilla.local +1 -0
  Bug#25289 - repair table causes "my_seek.c:56:
              my_seek: Assertion `fd != -1' failed"
  
  In difficult optimize/repair situations the server could crash.
  Under some circumstances the server retries an optimize/repair
  with more elaborate options. But it did not check if the first
  attempt failed so badly that a second one must not be tried.
  
  This could happen when a new data file has been created
  but it was not possible to open it. In this case the
  repair leaves behind a table with closed data file.
  This must not be used for another repair attempt.
  
  We do now detect the closed data file and do not try
  another repair attempt in this situation.
  
  No test case. The required table corruption can not be
  repeated easily. There is a test program attached to
  bug 25433.

I do not see better way to fix this problem. Patch is approved.

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/21620

ChangeSet@1.2608, 2007-03-09 16:07:25+01:00, istruewing@chilla.local +1 -0
  Bug#25289 - repair table causes "my_seek.c:56:
              my_seek: Assertion `fd != -1' failed"
  
  In difficult optimize/repair situations the server could crash.
  Under some circumstances the server retries an optimize/repair
  with more elaborate options. But it did not check if the first
  attempt failed so badly that a second one must not be tried.
  
  This could happen when a new data file has been created
  but it was not possible to open it. In this case the
  repair leaves behind a table with closed data file.
  This must not be used for another repair attempt.
  
  We do now detect the closed data file and do not try
  another repair attempt in this situation.
  
  No test case. The required table corruption can not be
  repeated easily. There is a test program attached to
  bug 25433.

The new patch (I hope the bug databse will find it soon) does now print a note. In the error log you can find something like this:
070314 16:54:43 [Note] Retrying repair of: './test/t1' with keycache
070314 16:54:43 [Note] Retrying repair of: './test/t1' failed. Please try REPAIR EXTENDED or myisamchk

Magnuns, plese check the updated fix when the bug database finds it.
Regards, Ingo

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/21895

ChangeSet@1.2472, 2007-03-14 16:45:57+01:00, istruewing@chilla.local +1 -0
  Bug#25289 - repair table causes "my_seek.c:56:
              my_seek: Assertion `fd != -1' failed"
  After merge fix

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/21896

ChangeSet@1.2422, 2007-03-14 16:41:57+01:00, istruewing@chilla.local +1 -0
  Bug#25289 - repair table causes "my_seek.c:56:
              my_seek: Assertion `fd != -1' failed"
  After merge fix

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/21904

ChangeSet@1.2608, 2007-03-14 15:54:37+01:00, istruewing@chilla.local +1 -0
  Bug#25289 - repair table causes "my_seek.c:56:
              my_seek: Assertion `fd != -1' failed"
  
  In difficult optimize/repair situations the server could crash.
  Under some circumstances the server retries an optimize/repair
  with more elaborate options. But it did not check if the first
  attempt failed so badly that a second one must not be tried.
  
  This could happen when a new data file has been created
  but it was not possible to open it. In this case the
  repair leaves behind a table with closed data file.
  This must not be used for another repair attempt.
  
  We do now detect the closed data file and do not try
  another repair attempt in this situation.
  
  No test case. The required table corruption can not be
  repeated easily. There is a test program attached to
  bug 25433.

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/21903

ChangeSet@1.2608, 2007-03-14 16:27:37+01:00, istruewing@chilla.local +1 -0
  Bug#25289 - repair table causes "my_seek.c:56:
              my_seek: Assertion `fd != -1' failed"
  
  In difficult optimize/repair situations the server could crash.
  Under some circumstances the server retries an optimize/repair
  with more elaborate options. But it did not check if the first
  attempt failed so badly that a second one must not be tried.
  
  This could happen when a new data file has been created
  but it was not possible to open it. In this case the
  repair leaves behind a table with closed data file.
  This must not be used for another repair attempt.
  
  We do now detect the closed data file and do not try
  another repair attempt in this situation.
  
  No test case. The required table corruption can not be
  repeated easily. There is a test program attached to
  bug 25433.

Queued to 5.1-engines, 5.0-engines, 4.1-engines.

Pushed into 5.1.18-beta

Pushed into 5.0.40

Pushed to 4.1.23

Noted in 4.1.23, 5.0.40, 5.1.18 changelogs.

Difficult repair or optimization operations could cause an assertion
failure, resulting in a server crash.