From: Aaron Conole <aconole@redhat.com>
To: David Marchand <david.marchand@redhat.com>
Cc: dev@dpdk.org, Michael Santana <maicolgabriel@hotmail.com>,
Olivier Matz <olivier.matz@6wind.com>
Subject: Re: [dpdk-dev] [RFC PATCH] ci: catch coredumps
Date: Mon, 11 Jan 2021 08:17:10 -0500 [thread overview]
Message-ID: <f7to8hv7gvd.fsf@dhcp-25.97.bos.redhat.com> (raw)
In-Reply-To: <20210111100146.3485-1-david.marchand@redhat.com> (David Marchand's message of "Mon, 11 Jan 2021 11:01:46 +0100")
David Marchand <david.marchand@redhat.com> writes:
> Parts of the unit tests code rely on forked/secondary processes
> (expectedly) failing.
> A crash in those situations could be missed so add a check on coredumps
> presence after unit tests have run.
>
> In some situations (like explicitly call rte_panic), coredump generation
> must be disabled to avoid false positives.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> Sending as a RFC, as this is a "nice to have" patch I had in store for
> some time, but I did not see the actual need so far.
>
> We could attach the coredumps in GHA result, but it would be hardly usable
> without attaching all generated binaries...
> Opinions?
I think it's a good start. We may not need to attach the binaries at
all - if we have access to gdb, we can run a script to just run simple
commands like 'thread apply all bt' and maybe some info commands. That
can all be stuffed into the logs. Usually a source level backtrace is
enough to work through what happened.
> ---
> .ci/linux-build.sh | 8 ++++++++
> app/test/test_debug.c | 11 +++++++++--
> app/test/test_mbuf.c | 9 ++++++++-
> 3 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
> index d2c821adf3..d00a5804b4 100755
> --- a/.ci/linux-build.sh
> +++ b/.ci/linux-build.sh
> @@ -57,7 +57,11 @@ meson build --werror $OPTS
> ninja -C build
>
> if [ "$AARCH64" != "true" ]; then
> + ulimit -c unlimited
> + sudo sysctl -w kernel.core_pattern=/tmp/dpdk-core.%e.%p
> +
> devtools/test-null.sh
> + ! ls /tmp/dpdk-core.*.* 2>/dev/null
> fi
>
> if [ "$ABI_CHECKS" = "true" ]; then
> @@ -102,5 +106,9 @@ if [ "$ABI_CHECKS" = "true" ]; then
> fi
>
> if [ "$RUN_TESTS" = "true" ]; then
> + ulimit -c unlimited
> + sudo sysctl -w kernel.core_pattern=/tmp/dpdk-core.%e.%p
> +
> sudo meson test -C build --suite fast-tests -t 3
> + ! ls /tmp/dpdk-core.*.* 2>/dev/null
> fi
> diff --git a/app/test/test_debug.c b/app/test/test_debug.c
> index 834a7386f5..23b24db177 100644
> --- a/app/test/test_debug.c
> +++ b/app/test/test_debug.c
> @@ -4,6 +4,8 @@
>
> #include <stdio.h>
> #include <stdint.h>
> +#include <sys/resource.h>
> +#include <sys/time.h>
> #include <sys/wait.h>
> #include <unistd.h>
>
> @@ -28,9 +30,14 @@ test_panic(void)
>
> pid = fork();
>
> - if (pid == 0)
> + if (pid == 0) {
> + struct rlimit rl;
> +
> + /* No need to generate a coredump when panicking. */
> + rl.rlim_cur = rl.rlim_max = 0;
> + setrlimit(RLIMIT_CORE, &rl);
> rte_panic("Test Debug\n");
> - else if (pid < 0){
> + } else if (pid < 0) {
> printf("Fork Failed\n");
> return -1;
> }
> diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
> index a40f7d4883..47a7b197d7 100644
> --- a/app/test/test_mbuf.c
> +++ b/app/test/test_mbuf.c
> @@ -1174,6 +1174,8 @@ test_refcnt_mbuf(void)
> }
>
> #include <unistd.h>
> +#include <sys/resource.h>
> +#include <sys/time.h>
> #include <sys/wait.h>
>
> /* use fork() to test mbuf errors panic */
> @@ -1186,9 +1188,14 @@ verify_mbuf_check_panics(struct rte_mbuf *buf)
> pid = fork();
>
> if (pid == 0) {
> + struct rlimit rl;
> +
> + /* No need to generate a coredump when panicking. */
> + rl.rlim_cur = rl.rlim_max = 0;
> + setrlimit(RLIMIT_CORE, &rl);
> rte_mbuf_sanity_check(buf, 1); /* should panic */
> exit(0); /* return normally if it doesn't panic */
> - } else if (pid < 0){
> + } else if (pid < 0) {
> printf("Fork Failed\n");
> return -1;
> }
next prev parent reply other threads:[~2021-01-11 13:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-11 10:01 David Marchand
2021-01-11 13:17 ` Aaron Conole [this message]
2021-01-25 15:05 ` [dpdk-dev] [PATCH v2] " David Marchand
2021-03-02 16:16 ` Luca Boccassi
2021-03-02 21:17 ` Aaron Conole
2021-03-03 9:03 ` David Marchand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f7to8hv7gvd.fsf@dhcp-25.97.bos.redhat.com \
--to=aconole@redhat.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=maicolgabriel@hotmail.com \
--cc=olivier.matz@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).