Bug #43631 Error "176 when fixing table" during ALTER ENABLE KEYS on a large table
Submitted: 13 Mar 2009 12:34 Modified: 31 Jul 2009 13:52
Reporter: Philip Stoev Email Updates:
Status: Can't repeat Impact on me:
Category:MySQL Server Severity:S2 (Serious)
Version:6.0.10 OS:Any
Assigned to: CPU Architecture:Any

[13 Mar 2009 12:34] Philip Stoev
When executing the alter_table test from the large_test suite, server returned error "176 when fixing table" when doing ALTER TABLE ENABLE KEYS on a table with 4 billion rows.

perror reports that error 176 is:

MySQL error code 176: File too short; Expected more data in file

There was plenty of hard disk space for the test. The server error log did not record anything.

This is very likely a regression, however since this test was not run frequently, it is not possible to establish when the regression occured.

How to repeat:
MTR_VERSION=1 perl mysql-test-run.pl --big-test --master_port=123456 --suite=large_tests --testcase-timeout=10000 --suite-timeout=100000

note that more than 50 GB of free disk space may be required to run this test.

Suggested fix:
Apart from fixing the underlying issue, a more descriptive error message would be appreciated.
[27 Jul 2009 8:59] Sveta Smirnova
Thank you for the report.

With current azalea tree I don't get error described, but crash instead:

Program terminated with signal 11, Segmentation fault.
#0  0x0000003429e0b002 in pthread_kill () from /lib64/libpthread.so.0
(gdb) bt
#0  0x0000003429e0b002 in pthread_kill () from /lib64/libpthread.so.0
#1  0x0000000000b4a844 in my_write_core (sig=11) at stacktrace.c:309
#2  0x00000000006bf73a in handle_segfault (sig=11) at mysqld.cc:2718
#3  <signal handler called>
#4  0x00000000006dd5be in reload_acl_and_cache (thd=0x0, options=32815, tables=0x0, write_to_binlog=0x40a410ef) at sql_parse.cc:6862
#5  0x00000000006c002f in signal_hand (arg=0x0) at mysqld.cc:2964
#6  0x0000003429e061b5 in start_thread () from /lib64/libpthread.so.0
#7  0x00000034292cd39d in clone () from /lib64/libc.so.6
#8  0x0000000000000000 in ?? ()

While version 5.1 runs fine. Please check in your environment if it behaves in same way or I have different problem.
[27 Jul 2009 12:15] Philip Stoev
Sveta, I think that the crash you are seeing is a separate bug. The backtrace shows that mysqld got a signal that it was unable to handle properly. This is not related to the bug in question.

Please try your test a couple times more and if the crash is repeatable, please file it as a separate bug (especially if you did something that would cause a signal to be delivered to mysqld). I have not ever seen this crash personally.
[27 Jul 2009 21:11] Sveta Smirnova
Thank you for the feedback.

I could not repeat crash second time: probably was affected by different process first time. Although I can not repeat original problem with Azalea tree as well.
[31 Jul 2009 13:52] Philip Stoev
The crash reported by sveta is now bug

Bug #46495 Crash in reload_acl_and_cache on SIGHUP 

She reports the original bug is no longer repeatable, so closing as Can't Repeat.