* Re: [LTP] vma05: Fix false positives from stripped system libraries
[not found] ` <CAL0q8a5vePcnKkrPab+aK3U_qCaKvuUYw3NMNN=D-+fwE5TwOA@mail.gmail.com>
@ 2025-07-29 8:09 ` Naresh Kamboju
2025-07-29 13:14 ` Cyril Hrubis
0 siblings, 1 reply; 2+ messages in thread
From: Naresh Kamboju @ 2025-07-29 8:09 UTC (permalink / raw)
To: Ben Copeland; +Cc: Arnd Bergmann, Dan Carpenter, LTP List
+ ltp
+ arnd
On Mon, 28 Jul 2025 at 19:26, Ben Copeland <ben.copeland@linaro.org> wrote:
>
> Sorry I typo'ed Cyril email address.
>
> Regards
>
> Ben
>
> On Mon, 28 Jul 2025 at 14:37, Ben Copeland <ben.copeland@linaro.org> wrote:
> >
> > Hi Cyril / Petr,
> >
> > I hope you are doing well.
> >
> > I have been seeing a test case fail for several years. I recently
> > added a new device in LKFT and noticed vma05 failing. I bumped into
> > issue [1].
> >
> > Upon looking into this failure, I noticed the vma05 test currently
> > produces false positive failures by flagging any `??` symbols in gdb
> > backtraces as vDSO kernel bugs, including those from standard stripped
> > system libraries. This causes the test to fail on most production
> > systems where system libraries like libc.so.6 are stripped of debug
> > symbols.
> >
> > This fails when gdb shows backtraces like:
> > ```
> > #0 0x0000ffff8d427dc0 in ?? () from /lib/aarch64-linux-gnu/libc.so.6
> > #1 0x0000ffff8d3d6980 [PAC] in raise () from /lib/aarch64-linux-gnu/libc.so.6
> > #2 0x0000aaaac6000690 [PAC] in main () at vma05_vdso.c:5 ```
> > ```
> > The `??` symbols from libc.so.6 are normal (stripped system library),
> > but the test incorrectly interprets this as a vDSO kernel bug.
> >
> > I also preserve debug symbols for memory test when building ltp with
> > this change, when we build LTP.
> >
> > ```
> > -find ${INSDIR}/opt/ltp -type f -executable -exec sh -c "file -i '{}'
> > | grep -q 'executable; charset=binary'" \; -print | tee
> > ltp-exec-files.txt
> > +find ${INSDIR}/opt/ltp -type f -executable -not -path "*/mem/*" -exec
> > sh -c "file -i '{}' | grep -q 'executable; charset=binary'" \; -print
> > | tee ltp-exec-files.txt
> > ```
> >
> > From our side I have now stripped out the binaries, but also I believe
> > the vma05 test logic is flawed so I made some adjustments [2]. The
> > test now passes.
> >
> > I'm happy to put a PR up, but Anders and I thought it would make sense
> > to touch base and also see what you think. I guess the other question
> > is, does this problem lend itself to just this test case, or are there
> > others sitting around LTP?
> >
> > Regards,
> >
> > Ben
> >
> > 1: https://github.com/linux-test-project/ltp/issues/477
> > 2: https://github.com/bhcopeland/ltp/commit/67ecbfcfe2313c4b16ce7191ded9949fdf5728d9
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [LTP] vma05: Fix false positives from stripped system libraries
2025-07-29 8:09 ` [LTP] vma05: Fix false positives from stripped system libraries Naresh Kamboju
@ 2025-07-29 13:14 ` Cyril Hrubis
0 siblings, 0 replies; 2+ messages in thread
From: Cyril Hrubis @ 2025-07-29 13:14 UTC (permalink / raw)
To: Naresh Kamboju; +Cc: Ben Copeland, Arnd Bergmann, Dan Carpenter, LTP List
Hi!
> > > 2: https://github.com/bhcopeland/ltp/commit/67ecbfcfe2313c4b16ce7191ded9949fdf5728d9
Filtering out records with /lib/ and /usr/lib/ looks reasonable to me.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-07-29 13:14 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CAL0q8a7ZKQKN2U-tWDaAui9Yr47oZGZgiF3qdxTaX8+-6Aogzg@mail.gmail.com>
[not found] ` <CAL0q8a5vePcnKkrPab+aK3U_qCaKvuUYw3NMNN=D-+fwE5TwOA@mail.gmail.com>
2025-07-29 8:09 ` [LTP] vma05: Fix false positives from stripped system libraries Naresh Kamboju
2025-07-29 13:14 ` Cyril Hrubis
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.