Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
5.5.29
-
None
-
None
-
Linux, ppc32
Description
The test main.myisampack is failing with message:
myisamchk: error: myisam_sort_buffer_size is too small
It works fine on all other arches I tested: s390 (32 and 64), i686, x86_64 or ppc64.
Even though I don't have direct access to any ppc32 I was able to put some outputs into the code and run it on a building machine. It really seems like buffer limit (sortbuff_size variable) is 0 when entering function _create_index_by_sort() at mariadb-5.5.29/storage/myisam/sort.c:104
I suspect some bad work with memory, especially with variable sizes. Particularly sort_buffer_size defined at mariadb-5.5.29/storage/myisam/ha_myisam.cc:77 seems to be ULONGLONG but the minimum value is casted to (long).
Similar situation is in mariadb-5.5.29/storage/myisam/myisamchk.c:295 where myisam_sort_buffer_size uses casting to long but after then we use it as ulonglong.
This is probably all the info I can provide right now, but I'll be happy to test a potential patch.
Attachments
Activity
Honza, I think the problem comes from the fact that check_param.sort_buffer_length is of size_t type, but because of GET_ULL, my_getopt does
(ulonglong)ptr= value;
I've fixed that by declaring check_param.sort_buffer_length to be ulonglong. Can you check if this patch fixes the issue:
=== modified file 'include/myisamchk.h'
— include/myisamchk.h 2011-11-22 17:04:38 +0000
+++ include/myisamchk.h 2013-03-07 15:59:39 +0000
@@ -138,9 +138,9 @@ typedef struct st_handler_check_param
/* Following is used to check if rows are visible */
ulonglong max_trid, max_found_trid;
ulonglong not_visible_rows_found;
+ ulonglong sort_buffer_length;
ulonglong use_buffers; /* Used as param to getopt() */
- size_t read_buffer_length, write_buffer_length;
- size_t sort_buffer_length, sort_key_blocks;
+ size_t read_buffer_length, write_buffer_length, sort_key_blocks;
time_t backup_time; /* To sign backup files */
ulong rec_per_key_part[HA_MAX_KEY_SEG * HA_MAX_POSSIBLE_KEY];
double new_rec_per_key_part[HA_MAX_KEY_SEG * HA_MAX_POSSIBLE_KEY];
Sergei, I've tested your patch and can confirm that the test case passes on ppc32, so the patch seems to be fine. Thanks.
I believe I've found the issue (compared myisam and aria files) and the following patch fixes the issue (test will pass on all arches):
diff -up mariadb-5.5.29/storage/myisam/myisamchk.c.sortbuffer mariadb-5.5.29/storage/myisam/myisamchk.c--- mariadb-5.5.29/storage/myisam/myisamchk.c.sortbuffer 2013-02-27 16:46:02.258855014 +0100+++ mariadb-5.5.29/storage/myisam/myisamchk.c 2013-02-27 16:46:23.456854430 +0100@@ -294,13 +294,13 @@ static struct my_option my_long_options[{ "sort_buffer_size", OPT_SORT_BUFFER_SIZE,"Deprecated. myisam_sort_buffer_size alias is being used",&check_param.sort_buffer_length,- &check_param.sort_buffer_length, 0, GET_ULL, REQUIRED_ARG,+ &check_param.sort_buffer_length, 0, GET_ULONG, REQUIRED_ARG,(long) SORT_BUFFER_INIT, (long) (MIN_SORT_BUFFER + MALLOC_OVERHEAD),SIZE_T_MAX, (long) MALLOC_OVERHEAD, (long) 1L, 0},{ "myisam_sort_buffer_size", OPT_SORT_BUFFER_SIZE,"Alias of sort_buffer_size parameter",&check_param.sort_buffer_length,- &check_param.sort_buffer_length, 0, GET_ULL, REQUIRED_ARG,+ &check_param.sort_buffer_length, 0, GET_ULONG, REQUIRED_ARG,(long) SORT_BUFFER_INIT, (long) (MIN_SORT_BUFFER + MALLOC_OVERHEAD),SIZE_T_MAX, (long) MALLOC_OVERHEAD, (long) 1L, 0},{ "sort_key_blocks", OPT_SORT_KEY_BLOCKS, "",