[MDEV-4186] Test case main.myisampack fails on ppc32 (only) Created: 2013-02-19  Updated: 2013-03-13  Resolved: 2013-03-08

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 5.5.29
Fix Version/s: 5.5.30

Type: Bug Priority: Major
Reporter: Honza Horak Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: None
Environment:

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.



 Comments   
Comment by Honza Horak [ 2013-02-27 ]

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, "",

Comment by Sergei Golubchik [ 2013-03-07 ]

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];
Comment by Honza Horak [ 2013-03-13 ]

Sergei, I've tested your patch and can confirm that the test case passes on ppc32, so the patch seems to be fine. Thanks.

Generated at Thu Feb 08 06:54:27 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.