Re: [dpdk-dev] Memory leak in rte_pci_scan

On Wed, Jun 16, 2021 at 6:27 PM Owen Hilyard [off-list ref] wrote:

quoted

- For the fast-tests testsuite, the default timeout should be 10s, not 600s.
See timeout_seconds_fast,
https://git.dpdk.org/dpdk/tree/app/test/meson.build#n446
Odd that a 600s timeout has been applied to fast-tests in your run.
How do you invoke meson?

# meson test -t 600

I copied the invocation from the production scripts for the community lab and removed the --suite argument.

600?
-t is for timeout multiplier.
The default timeout for fast tests is 10s and the logs in a previous
mail show 600s for timeout, so I would expect a 60 multiplier.

quoted

It seems like there are multiple dpdk processes running in // in this
environment.
Any idea of what is happening on your system at the moment you tried
to run this test?

I ran this on a VM that we keep in the same state as the production container runners. It is not attached to our Jenkins instance, and I was the only logged-in user.  I re-ran the test suite with and without ASAN, and it seems like this type of failure only happens when ASAN is active. The failing tests are: eal_flags_a_opt_autotest, eal_flags_b_opt_autotest, eal_flags_c_opt_autotest, eal_flags_main_opt_autotest, eal_flags_misc_autotest. I've attached the log.

ASAN seems to break some assumption on the default virtual base
address used by the mp stuff.
It might be a reason for the secondary process init failure.

Still, we have probably a deadlock here, since the test should fail in
a reasonable amount of time.

My guess would be at some secondary process not releasing a lock and
the primary ends up waiting on it.
Here, a secondary process did not initialise correctly, but it tried
to cleanup afterwards... per chance, do you have a crash reported in
syslog?


-- 
David Marchand