Bug #3192 | myisamchk crashes on attempt to repair a corrupted table | ||
---|---|---|---|
Submitted: | 16 Mar 2004 15:29 | Modified: | 25 Mar 2004 1:17 |
Reporter: | Sergey Petrunya | Email Updates: | |
Status: | Duplicate | Impact on me: | |
Category: | MySQL Server: MyISAM storage engine | Severity: | S3 (Non-critical) |
Version: | 5.0-bk | OS: | |
Assigned to: | Assigned Account | CPU Architecture: | Any |
[16 Mar 2004 15:29]
Sergey Petrunya
[16 Mar 2004 15:29]
Sergey Petrunya
Here is the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 8511)] 0x0807471f in sort_get_next_record (sort_param=0xbffff420) at mi_check.c:2685 2685 if (*killed_ptr(param->thd)) (gdb) bt #0 0x0807471f in sort_get_next_record (sort_param=0xbffff420) at mi_check.c:2685 #1 0x080743c6 in sort_key_read (sort_param=0xbffff420, key=0x0) at mi_check.c:2597 #2 0x0807bb7e in find_all_keys (info=0xbffff420, keys=64806, sort_keys=0x40148020, buffpek=0xbffff2c0, maxbuffer=0x bffff12c, tempfile=0xbffff200, tempfile_for_exceptions=0xbffff140) at sort.c:282 #3 0x0807b6c6 in _create_index_by_sort (info=0xbffff420, no_messages=1 '\001', sortbuff_size=2097116) at sort.c:181 #4 0x080727f9 in mi_repair_by_sort (param=0x816d2a0, info=0x81709c0, name=0x0, rep_quick=0) at mi_check.c:2021 #5 0x0805238f in myisamchk (param=0x816d2a0, filename=0xbffffa97 "t1") at myisamchk.c:956 #6 0x080511f5 in main (argc=0, argv=0x816fa10) at myisamchk.c:106 #7 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) #0 0x0807471f in sort_get_next_record (sort_param=0xbffff420) at mi_check.c:2685 #1 0x080743c6 in sort_key_read (sort_param=0xbffff420, key=0x0) at mi_check.c:2597 #2 0x0807bb7e in find_all_keys (info=0xbffff420, keys=64806, sort_keys=0x40148020, buffpek=0xbffff2c0, maxbuffer=0x bffff12c, tempfile=0xbffff200, tempfile_for_exceptions=0xbffff140) at sort.c:282 #3 0x0807b6c6 in _create_index_by_sort (info=0xbffff420, no_messages=1 '\001', sortbuff_size=2097116) at sort.c:181 #4 0x080727f9 in mi_repair_by_sort (param=0x816d2a0, info=0x81709c0, name=0x0, rep_quick=0) at mi_check.c:2021 #5 0x0805238f in myisamchk (param=0x816d2a0, filename=0xbffffa97 "t1") at myisamchk.c:956 #6 0x080511f5 in main (argc=0, argv=0x816fa10) at myisamchk.c:106 #7 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
[16 Mar 2004 15:43]
Sergey Petrunya
Test case uploaded to ftp://support.mysql.com/pub/mysql/secret/ as bug3192testcase.zip
[16 Mar 2004 17:34]
MySQL Verification Team
Only for the record, I tested against the 4.1.2 version on windows and I can't repeat: C:\mysql\data\bug3192testcase>myisamchk t1 Checking MyISAM file: t1 Data records: 64803 Deleted blocks: 1 myisamchk: warning: Table is marked as crashed and last repair failed - check file-size - check record delete-chain - check key delete-chain - check index reference - check data record references index: 1 myisamchk: error: Found 64804 keys of 64803 MyISAM-table 't1' is corrupted Fix it using switch "-r" or "-o" C:\mysql\data\bug3192testcase>myisamchk -r t1 - recovering (with sort) MyISAM-table 't1' Data records: 64803 - Fixing index 1 - Fixing index 2 - Fixing index 3 - Fixing index 4 - Fixing index 5 - Fixing index 6 - Fixing index 7 - Fixing index 8 - Fixing index 9 - Fixing index 10 - Fixing index 11 - Fixing index 12 C:\mysql\data\bug3192testcase I am now compiling the 5.0 BK tree and will come back here with my results.
[16 Mar 2004 19:14]
MySQL Verification Team
Ok latest BK tree 5.0 on Suse 9.0, I got the crash: (gdb) run -r /home/miguel/bug/t1 Starting program: /usr/local/mysql/bin/myisamchk -r /home/miguel/bug/t1 [New Thread 16384 (LWP 25187)] - recovering (with sort) MyISAM-table '/home/miguel/bug/t1' Data records: 64803 - Fixing index 1 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 25187)] 0x08074a2d in sort_get_next_record (sort_param=0xbfffee10) at mi_check.c:2685 2685 if (*killed_ptr(param->thd))
[25 Mar 2004 1:17]
Sergei Golubchik
Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the original bug instead. Thank you for your interest in MySQL. Additional info: see bug#3271