<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 6, 2017 at 5:53 AM, Cillian O'Donnell <span dir="ltr"><<a href="mailto:cpodonnell8@gmail.com" target="_blank">cpodonnell8@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 6 July 2017 at 08:05, Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br>
> On 05/07/2017 22:46, Cillian O'Donnell wrote:<br>
>><br>
>> Now the thing is, I might have to run RTEMS Tester about 3 times for<br>
>> the full testsuite before I can get the report, as the covoar runs<br>
>> will often hang on an arbitrary method and have to be manually exited<br>
>> and re-run.<br>
><br>
> How is covoar being run? Is it being run by the 'rtems-test' command?<br>
<br>
</span>Yes covoar runs after the testsuite if a --coverage flag is included<br>
with rtems-test command.<br>
<span class="">><br>
>> The point that this happens is not repeatable and there's<br>
>> no error message to go on.<br>
><br>
> Is it the covoar process that is stopping? Is it the process idle or using 100%?<br>
<br>
</span>Covoar locks up and becomes idle. Joel mentioned in the IRC meeting<br>
he's seen it before and I'll need to track down the exe causing it and<br>
debug it to get rid of this<br></blockquote><div><br></div><div>There must be a misunderstanding. I have never seen covoar lock up</div><div>like this. </div><div><br></div><div>It will ignore records when it thinks things are inconsistent. This can occur</div><div>when a method appears in two different executables and has different</div><div>sizes. The cause of this is usually padding at the end of the method so</div><div>the subsequent method in memory starts on a nice cache-line alignment.</div><div>The code tries to recognize the nops/padding at the end and ignore them.</div><div>When the padding inserted by ld changes or the objdump output being</div><div>parsed changes, covoar needs to be adjusted.</div><div><br></div><div>The ignored record message I saw is in the code that reads Couverture</div><div>trace records. The info in the record appears to be inconsistent with the</div><div>code to which it has been matched. This could be because the trace </div><div>record format has been changed or a simple bug.</div><div><br></div><div>From what I have seen, it is likely that it is primarily bugs in input processing.</div><div><br></div><div>But the code to do the "big union" of the trace data has to iterate over</div><div>all tests and all coverage blocks. It can take a while to run. I guess</div><div>there could be an infinite loop in it.  I always debugged it by having</div><div>a test case I could run in gdb.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">><br>
>> The only common theme is the methods will<br>
>> often be called thread...something. Even more rarely it will stop with<br>
>> the message 'resource temporarily unavailable'. I'm wondering is this<br>
>> normal behaviour for covoar on a long test-run? This never happens<br>
>> when running just the samples.<br>
><br>
> It is not normal behavior.<br></span></blockquote><div><br></div><div>+1</div><div><br></div><div>Is Linux or covoar printing the message? It holds all data in memory while </div><div>doing the analysis. Is it consuming a lot of RAM?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>> When a test run is successful it will also finish with a lot of these messages:<br>
>><br>
>> *** Trace block is inconsistent with coverage map<br>
>> *** Trace block (0x4000c4fc - 0x4000c51f) for 36 bytes<br>
>> *** Coverage map /home/cpod/coverage_test/test/<wbr>coverage/unlimited.exe.cov<br>
>> INFO: DesiredSymbols::<wbr>mergeCoverageMap - Unable to merge coverage map<br>
>> for _Thread_queue_Extract_with_<wbr>proxy because the sizes are different<br>
><br>
> I wonder what sizes are different?<br>
<br>
</span>For this one, Joel mentioned it could be something to do with nops<br>
being added or space not matching and to take a look at _Thread_<br>
queue_Extract_with_proxy  in the objdump and see if I can dig up<br>
anything from that. That message appears for _Thread_<br>
queue_Extract_with_proxy  on all tests from base_sp.exe to<br>
unlimited.exe when running the full testsuite and on a few instances<br>
it also mentions unable to merge coverage map for TOD_TICKS_PER_SECOND<br>
for the same reason. The mismatch is always 36 bytes.<br></blockquote><div><br></div><div>You need to find the two executables it differs on and see why the size</div><div>is different. It processes them from first to last on the command line so</div><div>find the first one that has the symbol and compare the dump to that</div><div>one it is flagging as different.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also I wanted to mention, there is quite a bit of work from the 2<br>
previous students on the integration of the coverage work into RTEMS<br>
Tester, would you be interested in starting the merging process of<br>
this. It might take a while to get everything reviewed and make any<br>
necessary changes. At this point it is working. its just fixing bugs,<br>
which I'm working on at the moment.<br></blockquote><div><br></div><div>Chris.. I suggested this. It seems the basic flow and integration of</div><div>coverage into the tester is good enough to review and merge. </div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
<br>
Cillian.<br>
<div class="HOEnZb"><div class="h5">><br>
> Chris<br>
______________________________<wbr>_________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br></div></div>