error while running rtems-test with coverage

Vijay Kumar Banerjee vijaykumar9597 at gmail.com
Mon Apr 16 07:23:03 UTC 2018 

the coverage is running now, shall we start a new mail thread for
covoar report ?

-- vijay

On 16 April 2018 at 12:35, Vijay Kumar Banerjee <vijaykumar9597 at gmail.com>
wrote:

> Ok thanks, so now we need to look into covoar.
> Do you have any sample output that will give me an idea of what it should
> look like ?
>
> On Mon, 16 Apr 2018, 11:13 Cillian O'Donnell, <cpodonnell8 at gmail.com>
> wrote:
>
>> Probably what'll happen is, when the reports are generating properly,
>> Chris will review the changes and come up with a list of blockers that must
>> be fixed before he would be happy accepting the code into rtems-tools
>> master. Then when that's done you can submit the patches.
>>
>> The thing with the data missing from the reports is tricky because
>> there's no error messages or log output to go on. Last time I seen that it
>> was because we were changing how the symbols were parsed and they were
>> being chopped up in odd ways and so none of them were found and so the
>> report was empty. This time I'm not sure because we haven't changed
>> anything like that. If I think of any clues, I'll let you know.
>>
>> On Mon, 16 Apr 2018, 05:36 Vijay Kumar Banerjee, <
>> vijaykumar9597 at gmail.com> wrote:
>>
>>>
>>>
>>> On 15 April 2018 at 15:33, Cillian O'Donnell <cpodonnell8 at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 15 April 2018 at 10:09, Cillian O'Donnell <cpodonnell8 at gmail.com>
>>>> wrote:
>>>>
>>>>> Not sure what's happening there. Send me a link to your github branch.
>>>>>
>>>>> On 15 April 2018 at 09:35, Vijay Kumar Banerjee <
>>>>> vijaykumar9597 at gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 15 April 2018 at 14:02, Cillian O'Donnell <cpodonnell8 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 15 April 2018 at 06:46, Vijay Kumar Banerjee <
>>>>>>> vijaykumar9597 at gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 15 April 2018 at 01:45, Cillian O'Donnell <cpodonnell8 at gmail.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Switch one of these lines out in qemu.cfg.
>>>>>>>>>
>>>>>>>>> #%define qemu_opts_base -no-reboot -monitor none -serial stdio
>>>>>>>>> -nographic
>>>>>>>>> #%define qemu_opts_base -no-reboot -serial null -serial mon:stdio
>>>>>>>>> -nographic
>>>>>>>>> %define qemu_opts_base -no-reboot -monitor null -serial stdio
>>>>>>>>> -nographic
>>>>>>>>>
>>>>>>>>> Just comment out the one that's being used and uncomment one of
>>>>>>>>> the others. It should cause a complaint when the tests are run and the qemu
>>>>>>>>> cmd should show up in the log so we can take a look at it.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> error: qemu.cfg:71: execute failed: qemu-system-sparc -no-reboot
>>>>>>>> -monitor null -serial stdio -nographic -no-reboot -monitor null -serial
>>>>>>>> stdio -nographic -M leon3_generic -kernel /home/lunatic/development/rtem
>>>>>>>> s/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.exe:
>>>>>>>> exit-code:1
>>>>>>>>
>>>>>>>> run: qemu-system-sparc -no-reboot -monitor null -serial stdio
>>>>>>>> -nographic -no-reboot -mo    nitor null -serial stdio -nographic -M
>>>>>>>> leon3_generic -kernel /home/lunatic/development/rtem
>>>>>>>> s/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.exe
>>>>>>>> -exec-trace     /home/lunatic/development/rte
>>>>>>>> ms/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimi
>>>>>>>> ted/unlimited.exe.cov
>>>>>>>>
>>>>>>>
>>>>>>> Are those line breaks actually there or is it from the copy and
>>>>>>> paste. Like  unlimi    ted. If so that's definitely the problem. What does
>>>>>>> your last section in qemu.cfg look like now? The execute section.
>>>>>>>
>>>>>> They are from copy paste .
>>>>>> I'm pasting the qemu.cfg here
>>>>>> .....
>>>>>>
>>>>>> #
>>>>>> # RTEMS Tools Project (http://www.rtems.org/)
>>>>>> # Copyright 2010-2014 Chris Johns (chrisj at rtems.org)
>>>>>> # All rights reserved.
>>>>>> #
>>>>>> # This file is part of the RTEMS Tools package in 'rtems-tools'.
>>>>>> #
>>>>>> # Redistribution and use in source and binary forms, with or without
>>>>>> # modification, are permitted provided that the following conditions
>>>>>> are met:
>>>>>> #
>>>>>> # 1. Redistributions of source code must retain the above copyright
>>>>>> notice,
>>>>>> # this list of conditions and the following disclaimer.
>>>>>> #
>>>>>> # 2. Redistributions in binary form must reproduce the above
>>>>>> copyright notice,
>>>>>> # this list of conditions and the following disclaimer in the
>>>>>> documentation
>>>>>> # and/or other materials provided with the distribution.
>>>>>> #
>>>>>> # this software is provided by the copyright holders and contributors
>>>>>> "as is"
>>>>>> # and any express or implied warranties, including, but not limited
>>>>>> to, the
>>>>>> # implied warranties of merchantability and fitness for a particular
>>>>>> purpose
>>>>>> # are disclaimed. in no event shall the copyright holder or
>>>>>> contributors be
>>>>>> # liable for any direct, indirect, incidental, special, exemplary, or
>>>>>> # consequential damages (including, but not limited to, procurement of
>>>>>> # substitute goods or services; loss of use, data, or profits; or
>>>>>> business
>>>>>> # interruption) however caused and on any theory of liability,
>>>>>> whether in
>>>>>> # contract, strict liability, or tort (including negligence or
>>>>>> otherwise)
>>>>>> # arising in any way out of the use of this software, even if advised
>>>>>> of the
>>>>>> # possibility of such damage.
>>>>>> #
>>>>>>
>>>>>> #
>>>>>> # qemu
>>>>>> #
>>>>>> # use a qemu command to run the executable in the qemu simulator.
>>>>>> #
>>>>>>
>>>>>> %include %{_configdir}/base.cfg
>>>>>> %include %{_configdir}/checks.cfg
>>>>>>
>>>>>> #
>>>>>> # console.
>>>>>> #
>>>>>> %define console_stdio
>>>>>> %include %{_configdir}/console.cfg
>>>>>>
>>>>>> #
>>>>>> # rtems version
>>>>>> #
>>>>>> %include %{_rtdir}/rtems/version.cfg
>>>>>>
>>>>>> #
>>>>>> # qemu common option patterns.
>>>>>> #
>>>>>> %define qemu_opts_base   -no-reboot -monitor none -serial stdio
>>>>>> -nographic
>>>>>> #%define qemu_opts_base   -no-reboot -serial null -serial mon:stdio
>>>>>> -nographic
>>>>>> #%define qemu_opts_base  -no-reboot -monitor null -serial stdio
>>>>>> -nographic
>>>>>> %define qemu_opts_no_net -net none
>>>>>> #
>>>>>> # qemu executable
>>>>>> #
>>>>>> %ifn %{defined bsp_qemu_opts}
>>>>>>  %define bsp_qemu_opts %{nil}
>>>>>> %endif
>>>>>> %define qemu_cmd  qemu-system-%{bsp_arch}
>>>>>> %define qemu_opts %{bsp_qemu_opts}
>>>>>>
>>>>>>
>>>>>> #
>>>>>> # Coverage analysis
>>>>>> #
>>>>>> %define coverage_arg %{nil}
>>>>>> %if %{defined _coverage}
>>>>>>     %if %{coverage_supported}
>>>>>>         %define coverage_arg -exec-trace %{test_executable}.cov
>>>>>>     %else
>>>>>>         %error "Coverage analysis unsupported for %{bsp}"
>>>>>>     %endif
>>>>>> %endif
>>>>>>
>>>>>> #
>>>>>> # executable
>>>>>> #
>>>>>>
>>>>>> #%execute %{qemu_cmd} %{qemu_opts} -kernel %{test_executable}
>>>>>> %execute %{qemu_cmd} %{qemu_opts_base} %{qemu_opts} -kernel
>>>>>> %{test_executable} %{coverage_arg}
>>>>>>
>>>>>
>>>> Just get rid of  %{qemu_opts_base} (Theres a double count of options)
>>>> and that should run without errors from the tester now. Unfortunately the
>>>> report generated wont contain any data so we've moved on to problems in
>>>> covoar now.
>>>>
>>> should I submit a patch now or should I apply the changes into current
>>> master and them submit ?
>>>
>>>>
>>>>>>
>>>>>> #%define qemu_opts_base -no-reboot -monitor none -serial stdio
>>>>>> -nographic
>>>>>> #%define qemu_opts_base -no-reboot -serial null -serial mon:stdio
>>>>>> -nographic
>>>>>> #%define qemu_opts_base -no-reboot -monitor null -serial stdio
>>>>>> -nographic
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 14 April 2018 at 20:37, Vijay Kumar Banerjee <
>>>>>>>>> vijaykumar9597 at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -- vijay
>>>>>>>>>>
>>>>>>>>>> On 15 April 2018 at 00:50, Vijay Kumar Banerjee <
>>>>>>>>>> vijaykumar9597 at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 14 April 2018 at 16:42, Cillian O'Donnell <
>>>>>>>>>>> cpodonnell8 at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 14 April 2018 at 07:11, Chris Johns <chrisj at rtems.org>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 14/4/18 8:02 am, Vijay Kumar Banerjee wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Getting this error now seems like something is missing.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ........
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> RTEMS Testing - Tester, 5 (b2ba08b0da42 modified)
>>>>>>>>>>>>>> Coverage environment prepared
>>>>>>>>>>>>>> Traceback (most recent call last):
>>>>>>>>>>>>>>    File "/home/lunatic/development/rte
>>>>>>>>>>>>>> ms/test/rtems-tools/tester/rtems-test", line 40, in <module>
>>>>>>>>>>>>>>      rt.test.run()
>>>>>>>>>>>>>>    File "/home/lunatic/development/rte
>>>>>>>>>>>>>> ms/test/rtems-tools/tester/rt/test.py", line 353, in run
>>>>>>>>>>>>>>      tst.reraise()
>>>>>>>>>>>>>>    File "/home/lunatic/development/rte
>>>>>>>>>>>>>> ms/test/rtems-tools/tester/rt/test.py", line 160, in reraise
>>>>>>>>>>>>>>      _test_reraise(*self.result)
>>>>>>>>>>>>>> NameError: global name '_test_reraise' is not defined
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> The reraise logic was moved to the rtemstoolkit last year:
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://git.rtems.org/rtems-tools/commit/?id=fa81491764861e6
>>>>>>>>>>>>> 3785a3faa241c488469087209
>>>>>>>>>>>>>
>>>>>>>>>>>>> It had some issues that have been fixed and it is being reused
>>>>>>>>>>>>> else where in the tester.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- vijay
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 13 April 2018 at 23:57, Vijay Kumar Banerjee <
>>>>>>>>>>>>>> vijaykumar9597 at gmail.com <mailto:vijaykumar9597 at gmail.com>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     On 13 April 2018 at 23:51, Cillian O'Donnell <
>>>>>>>>>>>>>> cpodonnell8 at gmail.com
>>>>>>>>>>>>>>     <mailto:cpodonnell8 at gmail.com>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         Hmmm it's not there. Even so I can almost guarantee
>>>>>>>>>>>>>> you, the
>>>>>>>>>>>>>>         reason it's not running is that coverage_supported
>>>>>>>>>>>>>> variable is
>>>>>>>>>>>>>>         not being found as true in qemu.cfg and so the the
>>>>>>>>>>>>>> command to
>>>>>>>>>>>>>>         generated the trace files isn't run and there's no
>>>>>>>>>>>>>> .cov files in
>>>>>>>>>>>>>>         the end. So that's what you'll have to dig into.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     Okay , I'll set it to global then.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Changes need to be on the latest version of master before I
>>>>>>>>>>>>> will review them. The failure above indicate the code you have is not up to
>>>>>>>>>>>>> date.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Yes that was the plan. Just to check Vijay your starting point
>>>>>>>>>>>> was using the ini-update branch from here?
>>>>>>>>>>>>
>>>>>>>>>>>> https://github.com/cillianodonnell/rtems-tools/tree/ini-update
>>>>>>>>>>>>
>>>>>>>>>>>> That branch is current rtems-tools master that I started to add
>>>>>>>>>>>> things back in. The only reraise in there is the one improrted from
>>>>>>>>>>>> rtemstoolkit.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> yes this is the branch I'm using , I checked the reraise error , not
>>>>>>>>>>> sure how it showed up buit I called it from the reraise module
>>>>>>>>>>> , and it got fixed . now I'm stuck here
>>>>>>>>>>>
>>>>>>>>>>> error: config error: qemu.cfg:36: No 'target' defined
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> okay , fixed that .
>>>>>>>>>> still getting the warnings of the unable to read .cov
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> are we supposed to set the bsp to global as well ?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> The change you have made is generating an exception in the
>>>>>>>>>>>>> tester thread. If you want to continue down this path you will need to fix
>>>>>>>>>>>>> what ever you have added.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The tests are run as threads separate from the main thread so
>>>>>>>>>>>>> the exception is caught and re-raised in the main thread letting you know.
>>>>>>>>>>>>> This is broken in the old code base you are using.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why not investigate the reason as indicated and sort if out
>>>>>>>>>>>>> what the new format configuration file needs?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Chris
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180416/d4ad2106/attachment-0002.html>

More information about the devel mailing list