On Thu, Oct 15, 2020 at 11:19 AM Gedare Bloom <ged...@rtems.org> wrote: > > On Thu, Oct 15, 2020 at 6:35 AM Joel Sherrill <j...@rtems.org> wrote: > > > > > > > > On Thu, Oct 15, 2020, 7:15 AM Alan Cudmore <alan.cudm...@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 <chr...@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.cudm...@gmail.com > >> > > <mailto:alan.cudm...@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@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
