From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13641 Path: news.gmane.org!.POSTED.ciao.gmane.org!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: Possibly spurious EAGAIN seen in pthread_key_create on x86 Date: Wed, 23 Jan 2019 06:22:35 +0100 Message-ID: <20190123052235.GC23924@voyager> References: <7ccdc4b9-c06e-5c76-6783-38f9cf297a14@adelielinux.org> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.org; posting-host="ciao.gmane.org:195.159.176.228"; logging-data="129653"; mail-complaints-to="usenet@ciao.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-13657-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 23 06:23:33 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by ciao.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gmB0e-000Xda-4i for gllmg-musl@m.gmane.org; Wed, 23 Jan 2019 06:23:32 +0100 Original-Received: (qmail 21968 invoked by uid 550); 23 Jan 2019 05:23:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 21950 invoked from network); 23 Jan 2019 05:23:29 -0000 Content-Disposition: inline In-Reply-To: <7ccdc4b9-c06e-5c76-6783-38f9cf297a14@adelielinux.org> X-Provags-ID: V03:K1:tmPbek50+S19nTlrPPlnOM7FurUfGV/AFUFX3eZYPF/waY8C/4u 5SqLc9MlsVoL4dBj0s4/PKEX3OCBjWWQL4XycL1NkyIhzkjR1atCu6u5mpJHJNx8AATlPpE iFzGX6V+cZ+wLIyxnaagZAWAucx5PJNg21xOAn7yE0fmZpCW74L+7TPMtjMFG7HnOueUjFH jg3HpAU3NiwKD7iOxjc0A== X-UI-Out-Filterresults: notjunk:1;V03:K0:qmz2mpvWifQ=:BjC3K83N7V5jM94g+LAADP XTuqMuO8kyklZylehuohb2jM8eCiAwZ6JIsLWu7zwGitCH6kls2ospSml04bMGW0jqlpVmfFR ZEJxcXrmxBuEuEEcw9T9DeHySjpc6F6gGyVUSsOATRcIj55hU9eXdxSOu9d0KhglJPAP2HWv4 HYnq/BoFGx/efsvZrWxNRoaoyg4B+SOV2WnyxNueDgQ3252fGMlgbUij0+qPAkXcbMiqJg5jJ yAs173NDPQlosKMld3YuAWE3mkqJLd6aWAJl7qJ4+a4/VGpYLiFp4Fga3XRK6BvqS1jiDwKEM 3vJFQ3exuoUurVKoZGxxiu13WFkWEUvi/q1j2VFhFRbgVB1rdC6WrK8CQkyzu4trSHvM20s1j x2QybaiEljVNgy2Z6zdO86crsgrl1Mxk/L+6S1RoZzzqrf6uAsuXAzVZMP5Jazv2N3+dq8BgX oUn0Lox5YtOOfw2GdW2hp2KK5OshBzMzMBfROrWdYyNUZmliDpvw6ZZFZCGx/apofZ9EOx+rS QJOErAcsS2uKQSXcSZ8lNtlMYrXAp3rBkGz3ponTRrm5XjiQr5NXcNTyB3a3LcHj5kAa8+a0J LGuTQG7boLV6Ece0OKdXo7teFjXFJ/eI8Cx8b1aZ8lQzqdM/4ld20G9lO1h4MOe2o1pA1WUJ+ +ttZzNcTDM+xV4DyPFh4mRzl3+0hJMfmcdxItaClBGcZAEezjmMozXiS2y3SlXV6hDYwHXqiD JUvN9KqCVN5XeFloTvDSR8Izb46xfiEMHuzDEIqw3bvQU/YT/p3BEeEqIJYhdejvIdpogYdH Xref: news.gmane.org gmane.linux.lib.musl.general:13641 Archived-At: 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