bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: test-pthread-rwlock failure on Pop!_OS 22.04 LTS


From: Bruno Haible
Subject: Re: test-pthread-rwlock failure on Pop!_OS 22.04 LTS
Date: Thu, 27 Jun 2024 16:46:22 +0200

Hi Paul,

> When running './gnulib-tool --test nstrftime" on my laptop's Pop!_OS 
> 22.04 LTS, test-pthread-rwlock went into what appeared to be a CPU bound 
> infinite loop. It would have drained the battery if I hadn't been 
> plugged into the wall. The process had many threads active. I eventually 
> gave up and killed the test.
> 
> Pop!_OS is downstream of Ubuntu, and this version is using glibc 
> 2.35-0ubuntu3.8. uname -srvmpi reports "Linux 6.9.3-76060903-generic 
> #202405300957~1718348209~22.04~7817b67 SMP PREEMPT_DYNAMIC Mon J x86_64 
> x86_64 x86_64".

Interesting. On my system — also 2.35-0ubuntu3.8 — the test completes
in ca. 7 seconds each time.

I'll try to reproduce and investigate.

From the details that you gave, the culprit could well be with the
kernel: Linux 6.9.3 ... PREEMPT_DYNAMIC.

> The laptop uses an Intel Core i5-1335U.

So, 'cat /proc/cpuinfo' shows 12 CPUs, right?

> The process had many threads active.

It should use 11 threads. You didn't see 100 threads, right?

> I suggest redoing the pthread tests so that they run in far less than 
> the current 10 minutes of real time before abandoning the test.

The test needs a certain number of rounds, in order to distinguish good
from bad implementations, as the comment says:
  /* Number of operations performed in each thread.
     This is quite high, because with a smaller count, say 5000, we often get
     an "OK" result even without ENABLE_LOCKING (on Linux/x86).  */
  #define REPEAT_COUNT 50000

The 10 minutes of timeout could certainly be reduced, at least when not
running in a QEMU-based VM.

> perhaps we should add a 
> new option --expensive to ./gnulib-tool, to cause it to also run 
> expensive tests, and mark the pthread tests as expensive.

gnulib-tool already has an option --with-longrunning-tests, for the same
purpose: Avoid exceedingly long test runs. Currently only a few tests modules
use it:
  fts-tests
  havelib-tests
  system-quote-tests
  vasnprintf-extra-tests
  vasnwprintf-extra-tests
  unistdio/u8-asnprintf-extra-tests
  unistdio/ulc-asnprintf-extra-tests
  obstack-zprintf-extra-tests

But let's investigate first...

Bruno






reply via email to

[Prev in Thread] Current Thread [Next in Thread]