[dpdk-dev] Memory leak in rte_pci_scan

[David Marchand]

On Wed, Jun 16, 2021 at 6:27 PM Owen Hilyard <ohilyard at iol.unh.edu> wrote:
>> - 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.


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