rtems-record-lttng: Corrupted timestamps after translating to CTF

[Joel Sherrill]

On Fri, Mar 5, 2021 at 12:00 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Fri, Mar 5, 2021 at 10:27 AM Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> >
> > On Fri, Mar 5, 2021 at 10:45 AM Sebastian Huber <
> sebastian.huber at embedded-brains.de> wrote:
> >>
> >> On 05/03/2021 16:11, Jan.Sommer at dlr.de wrote:
> >>
> >> > Some of the resulting CTF events have a very large timestamp. This
> only occurs for events of which are created by CPUs other than CPU0, but
> not all of them.
> >> > I ran rtems-record-lttng in gdb and could track it to
> record-client.c:176 (
> https://git.rtems.org/rtems-tools/tree/trace/record/record-client.c#n176).
> >> > There the (delta * ctx->to_bt_scaler ) causes an overflow and sets
> per_cpu->uptime.bt to a very large negative number which then later
> becomes a very large (positive) timestamp.
> >> >
> >> > I have some trouble figuring out what is going wrong here. The
> timestamps which are read from the rtems record events looks quite
> reasonable to me.
> >> > The to_bt_scaler is quite a large value and I don't fully get what it
> scales. Does someone have some hints?
> >> It could be related to ring buffer overflows. Do you get
> >> RTEMS_RECORD_PER_CPU_OVERFLOW items? There could be also some bugs in
> >> record-client.c. More unit tests for it would be helpful.
> >
> >
> > Asking stupidly, are there tests now? We didn't catch that libtrace was
> missing in the new coverage reports:
> >
> >
> https://ftp.rtems.org/pub/rtems/people/joel/coverage/coverage-2021-02-28/
> >
> > I can add it to the queue that libtrace is added. If more subsystems
> > are missing that we want to track coverage on, please point them out.
> >
>
> In cpukit the following are not covered. I have no strong opinion, but
> unless there is justification NOT to report on it, we should? Several
> of these don't have any tests, so then the question is whether they
> should have tests/examples written that use them.
>
> libdebugger
> libdl
> libdrvmgr
> libfs
> libgnat
> libi2c
> libmisc/capture
> libmisc/fb
> libmisc/monitor
> libmisc/mouse
> libmisc/redirector
> libmisc/rtems-fdt
> libmisc/serdbg
> libmisc/shell
> libmisc/utf8proc
> libmisc/uuid
> libmisc/xz
> libpci
> librtemscxx
> libtest
> libtrace
> mghttpd
> telnetd
> zlib
>
> It may be good just to know that our testsuite covers 0% of some of
> these directories, so that users can know... use at your own peril :o
>

I'm moving this part over to devel@ and a new thread.

--joel

>
> > --joel
> >>
> >>
> >> --
> >> embedded brains GmbH
> >> Herr Sebastian HUBER
> >> Dornierstr. 4
> >> 82178 Puchheim
> >> Germany
> >> email: sebastian.huber at embedded-brains.de
> >> phone: +49-89-18 94 741 - 16
> >> fax:   +49-89-18 94 741 - 08
> >>
> >> Registergericht: Amtsgericht München
> >> Registernummer: HRB 157899
> >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> >> Unsere Datenschutzerklärung finden Sie hier:
> >> https://embedded-brains.de/datenschutzerklaerung/
> >>
> >> _______________________________________________
> >> users mailing list
> >> users at rtems.org
> >> http://lists.rtems.org/mailman/listinfo/users
> >
> > _______________________________________________
> > users mailing list
> > users at rtems.org
> > http://lists.rtems.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20210318/0dd0c32f/attachment.html>