<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 15, 2021 at 5:09 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Mar 15, 2021 at 2:27 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Mar 15, 2021, 3:21 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
>><br>
>> On Fri, Mar 12, 2021 at 7:55 AM Ryan Long <<a href="mailto:ryan.long@oarcorp.com" target="_blank">ryan.long@oarcorp.com</a>> wrote:<br>
>> ><br>
>> > CID 26033: Dereference after null check in _Objects_Extend_information().<br>
>> ><br>
>> > Closes #4326<br>
>> > ---<br>
>> >  cpukit/score/src/objectextendinformation.c | 11 +++++++++++<br>
>> >  1 file changed, 11 insertions(+)<br>
>> ><br>
>> > diff --git a/cpukit/score/src/objectextendinformation.c b/cpukit/score/src/objectextendinformation.c<br>
>> > index 9796eb9..c669301 100644<br>
>> > --- a/cpukit/score/src/objectextendinformation.c<br>
>> > +++ b/cpukit/score/src/objectextendinformation.c<br>
>> > @@ -171,6 +171,17 @@ Objects_Maximum _Objects_Extend_information(<br>
>> ><br>
>> >      if ( old_maximum > extend_count ) {<br>
>> >        /*<br>
>> > +       * Coverity thinks there is a way for this to be NULL (CID #26033).<br>
>> > +       * After much time spent analyzing this, no one has identified the<br>
>> > +       * conditions where this can actually occur. Adding this _Assert ensures<br>
>> > +       * that it is never NULL. If this assert is triggered, condition<br>
>> > +       * generating this case will have been identified and it can be revisted.<br>
>> > +       * This is being done out of an abundance of caution since we could have<br>
>> > +       * easily flagged this as a false positive and ignored it completely.<br>
>> > +       */<br>
>> > +      _Assert(information->object_blocks != NULL);<br>
>> > +<br>
>> That's interesting. It would help if you could share your analysis.<br>
><br>
><br>
> This is the oldest Coverity issue that is open. It is over five years old. Chris and I have tried multiple times to figure out if it is valid. We never get any confidence that it cannot occur.<br>
><br>
>><br>
>> How does<br>
>> 70  if ( information->object_blocks == NULL ) {<br>
>> be true, and if it is true, how does the exectuion flow proceed in<br>
>> such a way that it will not reach this assert?<br>
><br>
><br>
> No idea but it apparently doesn't based on our tests.<br>
><br>
> Adding the assert is an attempt to finally find the case that trips this. It is either something I can never occur or something we don't know how to make happen. Either way the asserting like a good idea.<br>
><br>
> if you have a test case in mind that can reproduce this coverity path, let's try it and push this to failure. But we have no evidence that it's ever occurred in the field.<br>
<br>
Can information->object_blocks be NULL at line 70?<br></blockquote><div><br></div><div>Based on the coverage report case here, the answer is yes.<br><br><a href="https://ftp.rtems.org/pub/rtems/people/joel/coverage/coverage-2021-02-28/xilinx_zynq_a9_qemu-coverage/score/annotated.html#range67">https://ftp.rtems.org/pub/rtems/people/joel/coverage/coverage-2021-02-28/xilinx_zynq_a9_qemu-coverage/score/annotated.html#range67</a><br><br>Everything was covered in this method except that one error case. And it looks like there may be a covoar bug related to the branch that leads there since it says always taken and the destination is never executed. That can't happen.</div><div><br></div><div>This particular case was first reported by Coverity in Jan 2010. Chris and I have looked at it multiple times and never can figure out how it would happen. But we are not confident enough to mark it as false positive. Thus the _Assert() should be tripped if this ever happens, Coverity should be satisfied, and Chris and I won't worry we ignored something.</div><div><br></div><div>--joel</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>><br>
>><br>
>><br>
>> > +      /*<br>
>> >         *  Copy each section of the table over. This has to be performed as<br>
>> >         *  separate parts as size of each block has changed.<br>
>> >         */<br>
>> > --<br>
>> > 1.8.3.1<br>
>> ><br>
>> > _______________________________________________<br>
>> > devel mailing list<br>
>> > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>> _______________________________________________<br>
>> devel mailing list<br>
>> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>