DPDK patches and discussions
 help / color / mirror / Atom feed
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;
>  	}


  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).