X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; q=dns; s= default; b=qFr6/+j2RkzUjbllz4EHPjlte/gonW39J5s+8MQk+eybQa32n0a+s Y4xpxwNfTBKJ0XfmrijIJYuT+Tm5DiiBa8SbjijE+rilylU5Yvb/AaSf4ji4z38F 69CkJzqStOrTnyWUkKQas28i6tZnaADLoo8tn9N8ZBXunOkeGqUC1Y= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; s=default; bh=oWHM1UM63ShCw0daY01njPcRgnk=; b=rSKHvBaMN8AsICZbiMkWuznALl9Q HDj0eVBov75BnsT1jurg9GD7UjQ5CyDrgUmuyyuZTrl5zIV0jM9BdNysIN/KXigh CcBqMIeVtUePhZXlcwzJKgwteYB9DBuuz6fbS7Khdc806aaXcNGw2i0TIsNZL/DF oWc79T5pvLxzyHY= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-96.6 required=5.0 tests=BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_PBL,RDNS_DYNAMIC autolearn=ham version=3.3.2 spammy=slim, accident, highly X-HELO: calimero.vinschen.de Date: Wed, 20 Apr 2016 16:40:13 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Cc: "Canham, Timothy K (348C)" Subject: Re: pthread_attr_init() returning errors Message-ID: <20160420144013.GC25668@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com, "Canham, Timothy K (348C)" References: <20160420105016 DOT GB26118 AT calimero DOT vinschen DOT de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ALfTUftag+2gvp1h" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) --ALfTUftag+2gvp1h Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Apr 20 14:20, Canham, Timothy K (348C) wrote: >> From: Corinna Vinschen [mailto:corinna-cygwin AT cygwin DOT com]=20 >> On Apr 19 19:49, Canham, Timothy K (348C) wrote: >> > I have some code to start a task that suddenly started failing. This= =20 >> > is pretty mature code. Here is the code fragment with my added=20 >> > printf() >> >=20 >> > pthread_attr_t att; >> > int stat =3D pthread_attr_init(&att); >> > if (stat !=3D 0) { >> > printf("pthread_attr_init: (%d)(%d): %s\n",stat,errno,stre= rror(stat)); >> > // return >> > } >> >=20 >> > Here is the output: >> >=20 >> > pthread_attr_init: (16)(0): Device or resource busy >>=20 >> This is most unusual. What happens is this: >>=20 >> A pthread_attr_t is a pointer to a pointer to a struct with a magic >> number. And at the start of pthread_attr_init this magic number is >> tested if it's already the magic number expected for an object of >> type pthread_attr_t. And only if so, the pthread_attr_init function >> fails with EBUSY. >>=20 >> That means, the arbitrary value in the uninitialized att prior to the >> call to pthread_attr_init is a pointer value which points to valid >> memory which has the magic value 0xdf0df048. Wow. >>=20 >> This means we can't keep up with the tests in the pthread_FOO_init >> functions since they could point to an *supposedly* initialized >> object, while in fact the value they point to is only accidentally so >> that it looks like an initialized object. >>=20 >> I provided new developer snapshots on https://cygwin.com/snapshots/ >> and I've just uploaded a 2.5.1-0.1 test release which you can install >> via setup as soon as your mirror has catched up. >>=20 >> Pleaser give any of them a try. > > So what you are saying is that when pthread_attr_init() checked for > the magic number in supposedly uninitialized memory it found the exact > value of the magic number? That seems highly suspect. Seems like it > may be pointing to a valid previous entry. That may be the case. But in your example, pthread_attr_t att is very certainly uninitialized, being an uninitialized auto variable. So, if it actually points to an already initialized pthread_addr_t, it does so by accident, because the stack slot it was previously used by another, initialized pthread_addr_t. Therefore the check in pthread_attr_init is spurious. Apparently there's a chance, albeit slim, that it returns EBUSY due to a false positive. POSIX says: Results are undefined if pthread_attr_init() is called specifying an already initialized attr attributes object. And neither is EBUSY defined as a valid return value, nor are such checks performed in glibc. So I dropped the checks now in Cygwin as well. So, please give a dev snapshot or the 2.5.1-0.1 test release a try. Thanks, Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --ALfTUftag+2gvp1h Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXF5TNAAoJEPU2Bp2uRE+gFyIQAJelbnWXN6BG10F9hiB9/79H ywGdRY0szKRmt5qPCRt1H3rMFU+j7ry2kqxYdaV1y/wf+qymySv7Tvn3u/JyK+Lm CC4TiRo9TyUGUr94nz4D7l+xLvQkP2sIlJs7dG5/sb0S7oxnZRmv7teOvmGxMfIu tNB1zQQm/HiTo7w74CAM6wWnaFeyNw/FvtGFAUi2KEWAGakQOdRxqTONEgST55Iq hnxMzl9KskLCUvt4EwHymtlAVEtZgWPceYwMj+Ofntt45Qs/hCxdVIRCzIX79tbk bMxYS6XTr0Rr4PYEtyzRKvfw/MkDDxmEzyOvs9zoz0+z8zNmbCks5K5XTpjDwqUZ VLso44do8SogGuuW62LY3S8kKAYjdUOjtzrJyK87r6Gm1sSK0Vpy0ya3psC8zoy7 U2lK19eHeMjU2xWsRjncfyH/2kak1EZeLA3uVvDqWhhPEEynamgYvVQoxLe+e91e 9q8xmUmvBt6as8M3IIbdGaEyTgRnep/bGHPs0ZQrf35NvAxrA4ND2iVQ9CAMxNCh DZeBIeX1SeKpXRFYLt2nLmltyvsokooLYSj1kK9maeUjpzeqy9YR5W81h6t1uJtZ qqGP9S+NTWUe1X9pHUUzfdHs9q63hd0f+wGco9RK88w05qSe4DGR4JjoOde6qlRb cm0zk6+O0xqIhXj+CQJn =JQ0Y -----END PGP SIGNATURE----- --ALfTUftag+2gvp1h--