covoar SIGKILL Investigation

[Joel Sherrill]

On Tue, Aug 21, 2018, 1:59 PM Vijay Kumar Banerjee <vijaykumar9597 at gmail.com>
wrote:

>
>
> On Tue, Aug 21, 2018, 7:34 PM Joel Sherrill <joel at rtems.org> wrote:
>
>>
>>
>> On Tue, Aug 21, 2018 at 2:14 AM, Chris Johns <chrisj at rtems.org> wrote:
>>
>>> On 21/08/2018 16:55, Vijay Kumar Banerjee wrote:
>>> > I tried running coverage with this latest
>>> > master, covoar is taking up all the memory (7 GB) including the swap
>>> (7.6 GB)
>>> > and after a while, still gets killed. :(
>>>
>>> I ran rtems-test and created the .cov files and then ran covoar from the
>>> command
>>> line (see below). Looking at top while it is running I see covoar
>>> topping out
>>> with a size around 1430M. The size is pretty static once the "Loading
>>> symbol
>>> sets:" is printed.
>>>
>>> I have run covoar under valgrind with a smaller number of executables
>>> and made
>>> sure all the allocations are ok.
>>>
>>> I get a number of size mismatch messages related the inline functions
>>> but that
>>> is a known issue.
>>>
>>> > can there be something wrong with my environment?
>>>
>>> I have no idea.
>>>
>>> > I tried running it on a different system,
>>> > coverage did run for the whole testsuite for score and rtems only.
>>> > (I mentioned the symbols as argument to --coverage)
>>> > but it  doesn't run for all the symbol-sets, strange.
>>>
>>> I am not running coverage via the rtems-test command. I have been
>>> testing at the
>>> covoar command line.
>>>
>>> Can you please try a variant of:
>>>
>>>  /opt/work/chris/rtems/rt/rtems-tools.git/build/tester/covoar/covoar \
>>>  -v \
>>>  -S
>>>
>>> /opt/work/chris/rtems/rt/rtems-tools.git/tester/rtems/testing/coverage/leon3-qemu-symbols.ini
>>> \
>>>  -O /opt/work/chris/rtems/kernel/bsps/leon3/leon3-qemu-coverage/score \
>>>  -E
>>>
>>> /opt/work/chris/rtems/rt/rtems-tools.git/tester/rtems/testing/coverage/Explanations.txt
>>> \
>>>  -p RTEMS-5 `find . -name \*.exe`
>>> ?
>>>
>>> I have top running at the same time. The foot print grows while the
>>> DWARF info
>>> and .cov files are loaded which is
>>>
>>
>> Vijay .. I would add to make sure the gcov processing is turned off for
>> now.
>>
> it's turned off. :)
>

Just checking. That code isn't ready yet. :)

>
> After a lot of different attempts I realized that I just needed to waf
> build after pulling the new changes. Sorry about that.
>

Lol. It is always the dumb things.

It did run successfully !
> I'm now running coverage with rtems-test for the whole testsuite, I will
> be reporting about it soon :)
>

How long is covoar taking for the entire set?

Not that I am complaining, it takes minutes to do a doc build these days


>>> Thanks
>>> Chris
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180821/9fea351c/attachment-0001.html>