Re: Possibly spurious EAGAIN seen in pthread_key_create on x86

[Markus Wichmann <nullplan@gmx.net>]

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