MySQL Bugs: #1869: myisamchk fails fixing a table with blob column

Bug #1869	myisamchk fails fixing a table with blob column
Submitted:	18 Nov 2003 5:29	Modified:	24 Nov 2003 10:04
Reporter:	Miguel Solorzano	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: MyISAM storage engine	Severity:	S2 (Serious)
Version:		OS:	Linux (Suse/Windows XP)
Assigned to:	Michael Widenius	CPU Architecture:	Any

Description:
myisamchk presents the below error when trying to fix a table with
blob columns:

miguel@hegel:~/test> /home/miguel/mysql-4.0/myisam/myisamchk -r home/miguel/test/*.MYI
- recovering (with sort) MyISAM-table '/home/miguel/test/testrun.MYI'
Data records: 43968
- Fixing index 1
Wrong block with wrong total length starting at 76758748
myisamchk: error: Not enough memory for blob at 76758800
MyISAM-table '/home/miguel/test/testrun.MYI' is not fixed because of errors

How to repeat:
Sergei:

The file you should get at our irc:/tmp directory.

Suggested fix:
I don't know :)

I forget for to add Windows OS.

With same test files myisamchk from 4.1 crashes with Segmentation fault no matter what options it is stared with:

It always fails with following backtrace:

(gdb) bt
#0  0x40036a7e in pthread_mutex_lock () from /lib/tls/libpthread.so.0
#1  0x0809be7e in safe_mutex_lock (mp=0x5c, file=0x80b1fbf "mf_keycache.c", line=2056) at thr_mutex.c:95
#2  0x0808c7f3 in flush_key_blocks (keycache=0x0, file=6, type=FLUSH_FORCE_WRITE) at mf_keycache.c:2056
#3  0x0806d467 in chk_size (param=0x8167040, info=0x816a3b0) at mi_check.c:275
#4  0x08051eb1 in myisamchk (param=0x8167040, filename=0xbffff832 "testrun") at myisamchk.c:1017
#5  0x08050a29 in main (argc=0, argv=0x81694d8) at myisamchk.c:106

here there are two unrelated issues:

1. myisamchk reports "Not enough memory" - there is nothing we can fix here. It's true that 1G blob that myisamchk tries to load is not a real data, but results from a spurious match, where myisamchk finds a "row header" in the middle of your blob. Still, when doing repair myisamchk tries not to lose any data, thus if something looks like a row it should be restored - thus spurios rows can appear in the result. All you need is enough memory (or swap) to allocate 1G :) After all MyISAM table *can* legally have 1G blob, cannot it ?

I fixed "Error writing file 'UNOPENED'" error in myisamchk, and made "not enough memory" message somewhat less confusing - one no longer need to hack myisamchk to find out how much memory he was lacking.

2. myisamchk crash is not related to this, or to this table. It's because of multiple keycache support, was introduced a couple of days ago, and will be fixed today anyway.

Added by Monty option: --max-record-length=#

Changeset: 1.1630.1.2 03/11/23