MySQL Bugs: #19892: myisampack fails with glibc free() error

Bug #19892	myisampack fails with glibc free() error
Submitted:	17 May 2006 17:35	Modified:	29 Jun 2006 11:08
Reporter:	Dan Gregory	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	5.0.21	OS:	Linux (RHEL4)
Assigned to:		CPU Architecture:	Any

Description:
myisampack is failing with the following error on my SunFire x4200 (AMD x86_64) under RHEL4.

# mysql --version
mysql  Ver 14.12 Distrib 5.0.21, for unknown-linux-gnu (x86_64) using readline 5.0

# myisampack FOO.MYI
Compressing FOO.MYD: (18786235 records)
- Calculating statistics
- Compressing file
*** glibc detected *** free(): invalid next size (normal): 0x000000000091f2d0 ***
Aborted

Then I installed the x86 version to see if that helps any:

# mysql --version
mysql  Ver 14.12 Distrib 5.0.21, for pc-linux-gnu (i686) using readline 5.0
# myisampack --version
myisampack Ver 1.23 for pc-linux-gnu on i686

# myisampack FOO.MYI
Compressing FOO.MYD: (18786235 records)
- Calculating statistics
- Compressing file
*** glibc detected *** corrupted double-linked list: 0x081d8590 ***
Aborted

Which gives a different error, but looks suspiciously similar.

Taking the files over to a sparc platform fixes and packing over there fixes the issue but I'm running an older version of the server there:

$ mysql --version
mysql  Ver 14.12 Distrib 5.0.19, for sun-solaris2.9 (sparc) using readline 5.0

But the .19 version on AMD x86 doesn't appear to work either

How to repeat:
I have no idea how to repeat this test.  And unfortunately, I can't send the files.  The MYD is greater than 3G and it contains company private data in it.

Thank you for a problem report. Please, send your my.cnf file content. What glibc version is used?

I am using glibc-2.3.4-2.19 rpm package on RHEL4.

Here is my my.cnf

==================
[client]
port            = 3306
socket          = /tmp/mysql.sock

[mysqld]
port            = 3306
socket          = /tmp/mysql.sock
###skip-locking
key_buffer = 384M
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size = 32M
thread_concurrency = 8
#log-bin=mysql-bin
server-id       = 1
tmpdir          = /tmp/         

datadir=/var/lib/mysql/
max_connections=350
join_buffer_size=1M
max_connect_errors=10
query_cache_limit=10M
query_cache_type=1
#back_log=75
tmp_table_size=64M
query_prealloc_size = 32768
query_alloc_block_size = 32768

[mysqld_safe]
err-log=/var/log/mysql/mysqld.log
open_files_limit = 8192

[mysql.server]
user=mysql
## basedir=/usr/local/mysql

[safe_mysqld]
err-log=/var/log/mysql/mysqld.log
pid-file=/var/run/mysql/mysqld.pid
open_files_limit=8192

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash

[isamchk]
key_buffer = 2048M
sort_buffer_size = 2048M
read_buffer = 2M
write_buffer = 2M
tmpdir          = /tmp/         

[myisamchk]
key_buffer = 2048M
sort_buffer_size = 2048M
read_buffer = 2M
write_buffer = 2M
tmpdir   = /tmp

[mysqlhotcopy]
interactive-timeout

=======================

Thanks

Sorry for a delay with this bug report. Please, send the results of SHOW TABLE STATUS for that FOO table.

Unfortunately, I don't have the corrupt table anymore, nor do I have RHEL installed on those boxes anymore.  We did have some errors with our qfs file system between RHEL and Solaris that might have been the culprit.  Everything seems to run very smooth with Solaris 10 and mysql on x86-64.

I see no way to repeat/explain this behaviour now. Let's hope it was file system-related problem, not MySQL code-related one.