RTEMS 5.1 pc686 BSP malloc_info problem?

[Chris Johns]

On 13/10/20 4:13 am, Joel Sherrill wrote:
> On Mon, Oct 12, 2020 at 11:15 AM Alan Cudmore <alan.cudmore at gmail.com
> <mailto:alan.cudmore at gmail.com>> wrote:
> 
>     Hi Chris,
>     I'm not sure that I can easily create a test to show that this
>     condition exists. I think the rtems_rfs_bitmap_create_search function
>     works as it is intended to, but during the last iteration of the for
>     loop, if 'size' is zero and 'bit' is 31, the 'search_map' variable is
>     incremented once more, and the value of RTEMS_RFS_BITMAP_ELEMENT_CLEAR
>     (0xFFFFFFFF) is written to that location. This location is one address
>     beyond the memory that was allocated for the search_map in
>     rtems_rfs_bitmap_open.
>     I guess that most of the time this is a silent side effect, but my
>     application just happened to have memory lined up such that the extra
>     write causes the malloc Allocator mutex to fail, causing the
>     malloc_info call to block indefinitely. I would consider this a lucky
>     break!
>     The exact same example application does not fail on RTEMS 4.11. I
>     think the problem still exists, but in that case, the word that gets
>     written is different.
> 
>     Here are some debug printfs from rtems_rfs_bitmap_open and
>     rtems_rfs_bitmap_create_search:
> 
>     From rtems_rfs_bitmap_open:
>     RFS - rtems_rfs_bitmap_open - search_bits malloced size = 16 bytes
>     RFS - rtems_rfs_bitmap_open - addr of search_bits = 0x00C03814
>     RFS -> size of search_map = 4
>     RFS -> control->size = 4095
> 
>     From the subsequent call to rtems_rfs_bitmap_create_search:
>     These printfs are in the if clause where bit == 31 (line 633)
>     RFS --> search_map before increment addr 00C03814, size = 3071
>     RFS --> search_map after increment -> writing
>     RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03818
>     RFS --> search_map before increment addr 00C03818, size = 2047
>     RFS --> search_map after increment -> writing
>     RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C0381C
>     RFS --> search_map before increment addr 00C0381C, size = 1023
>     RFS --> search_map after increment -> writing
>     RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03820
>     RFS --> search_map before increment addr 00C03820, size = 0
>     RFS --> search_map after increment -> writing
>     RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03824
> 
>     It's this last write to 00C03824 that causes the problem. I think the
>     fix just involves checking to see if size == 0 before executing the if
>     clause. I wanted to be sure that this extra write was not needed.
> 
>     If you have an idea for a test case, I can work on it, but if you
>     think that this is good enough, I can propose a patch.
> 
>     Also, thanks for the idea of using RTEMS_DEBUG Sebastian, I need to
>     upgrade my RTEMS toolbox with the latest techniques.
> 
> 
> If, while analysing this issues, you came up with any consistency checks
> or assertions that can be added to the code when debug is enabled, 
> those would be welcomed. It is hard to go back and add them without 
> the analysis like you did hunting this bug.

I have added an _Assert (thanks Sebastian) and I now see:

*** BEGIN OF TEST FSRFSBITMAP 1 ***

*** TEST VERSION: 6.0.0.df9cc1aee87da6c6ba41d52454fa5f45fba74501

*** TEST STATE: EXPECTED_PASS

*** TEST BUILD: RTEMS_DEBUG

*** TEST TOOLS: 10.2.1 20200918 (RTEMS 6, RSB
ed5030bc24dbfdfac52074ed78cf4231bf1f353d, Newlib 749cbcc)
Initializing filesystem RFS

assertion "search_map >= control->search_bits && search_map <
(control->search_bits +
rtems_rfs_bitmap_elements(rtems_rfs_bitmap_elements(control->size)))" failed:
file "../../../cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c", line 648, function:
rtems_rfs_bitmap_create_search



I have a patch to fix this I will post.

Thank you Alan for the report and the analysis. It made my job nice and simple.

Chris