Possibly spurious EAGAIN seen in pthread_key_create on x86

Possibly spurious EAGAIN seen in pthread_key_create on x86

[A. Wilcox]

[-- Attachment #1.1: Type: text/plain, Size: 795 bytes --]

Hello there muslers,

While running the test suite for GLib++ (the C++ wrapper for GLib) on
our 32-bit x86 builder (i686), after upgrading to 1.1.21, it logged:


FAIL: glibmm_mainloop/test
==========================
GLib (gthread-posix.c): Unexpected error from C library during
'pthread_key_create': Resource temporarily unavailable.  Aborting.


Running the test suite an additional 160 (one hundred and sixty) times
could not repeat the result.  Still, I wanted to report it on the
off-chance there is some significance to this single result.

Importantly, I haven't noticed this failure on any of the other
architectures we've built GLib++ on (ppc32, ppc64, aarch64).

Best,
--arw

-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Possibly spurious EAGAIN seen in pthread_key_create on x86

[Rich Felker]

On Tue, Jan 22, 2019 at 03:15:35PM -0600, A. Wilcox wrote:
> Hello there muslers,
> 
> While running the test suite for GLib++ (the C++ wrapper for GLib) on
> our 32-bit x86 builder (i686), after upgrading to 1.1.21, it logged:
> 
> 
> FAIL: glibmm_mainloop/test
> ==========================
> GLib (gthread-posix.c): Unexpected error from C library during
> 'pthread_key_create': Resource temporarily unavailable.  Aborting.
> 
> 
> Running the test suite an additional 160 (one hundred and sixty) times
> could not repeat the result.  Still, I wanted to report it on the
> off-chance there is some significance to this single result.
> 
> Importantly, I haven't noticed this failure on any of the other
> architectures we've built GLib++ on (ppc32, ppc64, aarch64).

Can you figure out what this test is doing, or point to source so
others can? My best guess is that it's creating and destroying keys
very many times, and something happened that caused the dirty-slot
reclaiming __synccall to fail (maybe EMFILE or ENFILE?).

Rich

Re: Possibly spurious EAGAIN seen in pthread_key_create on x86

[Markus Wichmann]

On Tue, Jan 22, 2019 at 03:15:35PM -0600, A. Wilcox wrote:
> Hello there muslers,
> 
> While running the test suite for GLib++ (the C++ wrapper for GLib) on
> our 32-bit x86 builder (i686), after upgrading to 1.1.21, it logged:
> 
> 
> FAIL: glibmm_mainloop/test
> ==========================
> GLib (gthread-posix.c): Unexpected error from C library during
> 'pthread_key_create': Resource temporarily unavailable.  Aborting.
> 
> 
> Running the test suite an additional 160 (one hundred and sixty) times
> could not repeat the result.  Still, I wanted to report it on the
> off-chance there is some significance to this single result.
> 
> Importantly, I haven't noticed this failure on any of the other
> architectures we've built GLib++ on (ppc32, ppc64, aarch64).
> 
> Best,
> --arw
> 
> -- 
> A. Wilcox (awilfox)
> Project Lead, Adélie Linux
> https://www.adelielinux.org
> 


That error message is the message for EAGAIN. pthread_key_create()
returns EAGAIN if found_dirty == 0 or clean_dirty_tsd() failed. The
former would mean that the test suite tried to create more than
PTHREAD_KEYS_MAX keys, but since that value is static, barring a weird
usage pattern, you'd get the error always.

So it's going to be the latter. clean_dirty_tsd() does a synccall. It
will return an error if the calling thread is unable to signal itself
enough to run the callback. Or, if somehow the value of __pthread_self()
changed between the start of clean_dirty_tsd() and the end of
clean_dirty_tsd_callback(), but that is space fairy territory, isn't it?

No, the only way I see to get through __synccall() without calling the
callback at least in the calling thread, is to go to the label "out:",
which only happens if /proc/self/task could not be opened.

So I guess you ran afoul of a temporary failure in open(), then.

Ciao,
Markus