<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 15, 2020, 7:15 AM Alan Cudmore <<a href="mailto:alan.cudmore@gmail.com">alan.cudmore@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for all of the help, and thanks for the patch Chris! I was<br>
hoping to submit a patch this weekend, so you just gave me back some<br>
time :)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Glad you found this! </div><div dir="auto"><br></div><div dir="auto">The RFS was new in 4.10 as I recall. You guys have missions using this. Do you need to locally fix this?</div><div dir="auto"><br></div><div dir="auto">It also needs to be fixed in 4.11. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Alan<br>
<br>
On Thu, Oct 15, 2020 at 2:08 AM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a>> wrote:<br>
><br>
> On 13/10/20 4:13 am, Joel Sherrill wrote:<br>
> > On Mon, Oct 12, 2020 at 11:15 AM Alan Cudmore <<a href="mailto:alan.cudmore@gmail.com" target="_blank" rel="noreferrer">alan.cudmore@gmail.com</a><br>
> > <mailto:<a href="mailto:alan.cudmore@gmail.com" target="_blank" rel="noreferrer">alan.cudmore@gmail.com</a>>> wrote:<br>
> ><br>
> >     Hi Chris,<br>
> >     I'm not sure that I can easily create a test to show that this<br>
> >     condition exists. I think the rtems_rfs_bitmap_create_search function<br>
> >     works as it is intended to, but during the last iteration of the for<br>
> >     loop, if 'size' is zero and 'bit' is 31, the 'search_map' variable is<br>
> >     incremented once more, and the value of RTEMS_RFS_BITMAP_ELEMENT_CLEAR<br>
> >     (0xFFFFFFFF) is written to that location. This location is one address<br>
> >     beyond the memory that was allocated for the search_map in<br>
> >     rtems_rfs_bitmap_open.<br>
> >     I guess that most of the time this is a silent side effect, but my<br>
> >     application just happened to have memory lined up such that the extra<br>
> >     write causes the malloc Allocator mutex to fail, causing the<br>
> >     malloc_info call to block indefinitely. I would consider this a lucky<br>
> >     break!<br>
> >     The exact same example application does not fail on RTEMS 4.11. I<br>
> >     think the problem still exists, but in that case, the word that gets<br>
> >     written is different.<br>
> ><br>
> >     Here are some debug printfs from rtems_rfs_bitmap_open and<br>
> >     rtems_rfs_bitmap_create_search:<br>
> ><br>
> >     From rtems_rfs_bitmap_open:<br>
> >     RFS - rtems_rfs_bitmap_open - search_bits malloced size = 16 bytes<br>
> >     RFS - rtems_rfs_bitmap_open - addr of search_bits = 0x00C03814<br>
> >     RFS -> size of search_map = 4<br>
> >     RFS -> control->size = 4095<br>
> ><br>
> >     From the subsequent call to rtems_rfs_bitmap_create_search:<br>
> >     These printfs are in the if clause where bit == 31 (line 633)<br>
> >     RFS --> search_map before increment addr 00C03814, size = 3071<br>
> >     RFS --> search_map after increment -> writing<br>
> >     RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03818<br>
> >     RFS --> search_map before increment addr 00C03818, size = 2047<br>
> >     RFS --> search_map after increment -> writing<br>
> >     RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C0381C<br>
> >     RFS --> search_map before increment addr 00C0381C, size = 1023<br>
> >     RFS --> search_map after increment -> writing<br>
> >     RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03820<br>
> >     RFS --> search_map before increment addr 00C03820, size = 0<br>
> >     RFS --> search_map after increment -> writing<br>
> >     RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03824<br>
> ><br>
> >     It's this last write to 00C03824 that causes the problem. I think the<br>
> >     fix just involves checking to see if size == 0 before executing the if<br>
> >     clause. I wanted to be sure that this extra write was not needed.<br>
> ><br>
> >     If you have an idea for a test case, I can work on it, but if you<br>
> >     think that this is good enough, I can propose a patch.<br>
> ><br>
> >     Also, thanks for the idea of using RTEMS_DEBUG Sebastian, I need to<br>
> >     upgrade my RTEMS toolbox with the latest techniques.<br>
> ><br>
> ><br>
> > If, while analysing this issues, you came up with any consistency checks<br>
> > or assertions that can be added to the code when debug is enabled,<br>
> > those would be welcomed. It is hard to go back and add them without<br>
> > the analysis like you did hunting this bug.<br>
><br>
> I have added an _Assert (thanks Sebastian) and I now see:<br>
><br>
> *** BEGIN OF TEST FSRFSBITMAP 1 ***<br>
><br>
> *** TEST VERSION: 6.0.0.df9cc1aee87da6c6ba41d52454fa5f45fba74501<br>
><br>
> *** TEST STATE: EXPECTED_PASS<br>
><br>
> *** TEST BUILD: RTEMS_DEBUG<br>
><br>
> *** TEST TOOLS: 10.2.1 20200918 (RTEMS 6, RSB<br>
> ed5030bc24dbfdfac52074ed78cf4231bf1f353d, Newlib 749cbcc)<br>
> Initializing filesystem RFS<br>
><br>
> assertion "search_map >= control->search_bits && search_map <<br>
> (control->search_bits +<br>
> rtems_rfs_bitmap_elements(rtems_rfs_bitmap_elements(control->size)))" failed:<br>
> file "../../../cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c", line 648, function:<br>
> rtems_rfs_bitmap_create_search<br>
><br>
><br>
><br>
> I have a patch to fix this I will post.<br>
><br>
> Thank you Alan for the report and the analysis. It made my job nice and simple.<br>
><br>
> Chris<br>
</blockquote></div></div></div>