[PATCH 1/2] covoar/CoverageReaderQEMU: Fix infinite loop

Joel Sherrill joel at rtems.org
Mon Mar 15 23:00:57 UTC 2021


On Mon, Mar 15, 2021 at 5:58 PM Chris Johns <chrisj at rtems.org> wrote:

> On 16/3/21 9:11 am, Gedare Bloom wrote:
> > On Mon, Mar 15, 2021 at 3:34 PM Alex White <alex.white at oarcorp.com
> > <mailto:alex.white at oarcorp.com>> wrote:
> >
> >     I honestly can't remember why I changed 1024 to 20,000.
> >
> >     I've looked back at that code and changed it back to 1024 without any
> >     issues. I think I might have missed that this is all happening in a
> loop,
> >     and at one point during a (long) debugging session I convinced
> myself that
> >     it wasn't reading all of the entries.
> >
> >     At least that's the most rational explanation I can think up for that
> >     particular change. 😊
> >
> >     If I revert ENTRIES from 20000 back to 1024, are we satisfied to
> leave the
> >     "entries" array as-is?
> >
> > I think that Chris' main points here are that, as you get covoar working
> again
> > and cleaning it up, it should be made more C++ (and less C).
>
> Thanks Gedare, yes I am asking if this could be considered. A total
> conversion
> is not realistic and would be asking too much but my hope is making
> changes in
> small pieces can be done. Some changes will requiring new C++ skills but
> that
> should be thought of as a fun challenge.
>
> In this case I think changing to a vector would be a good thing for 1024
> entries
> but we had 1024 in the code previously and it was fine so I am also OK if
> it
> left that way.
>


This is a different case than many of the others, it is reading a block of
fixed size
binary entries from the Qemu trace log. It is just avoiding reading the
32-byte
entries one at a time. It is read, process, and discard. How would
std::ANYTHING help here?

--joel


>
> Chris
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210315/1b06a0eb/attachment.html>


More information about the devel mailing list