RTEMS 5.1 pc686 BSP malloc_info problem?

Thu Oct 15 18:22:35 UTC 2020

On Thu, Oct 15, 2020 at 11:19 AM Gedare Bloom <gedare at rtems.org> wrote:
>
> On Thu, Oct 15, 2020 at 6:35 AM Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> >
> > On Thu, Oct 15, 2020, 7:15 AM Alan Cudmore <alan.cudmore at gmail.com> wrote:
> >>
> >> Thanks for all of the help, and thanks for the patch Chris! I was
> >> hoping to submit a patch this weekend, so you just gave me back some
> >> time :)
> >
> >
> > Glad you found this!
> >
> > The RFS was new in 4.10 as I recall. You guys have missions using this. Do you need to locally fix this?

We have one active mission that uses it. I will be worth trying to
determine what word of memory is affected before trying to fix it,
since it has been operating normally for 5.5 years with the issue.

> >
> > It also needs to be fixed in 4.11.
> >
> > For posterity, if a fix is needed for 4.10, should we push it even though we have no plans for a future release from that branch? Just asking since a small number of other patches have been pushed to that branch.
> >
> Yes.
>
> >
> >
> >> Alan
> >>
> >> On Thu, Oct 15, 2020 at 2:08 AM Chris Johns <chrisj at rtems.org> wrote:
> >> >
> >> > 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
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel