delorie.com/archives/browse.cgi | search |
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: | <cygwin.cygwin.com> |
List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com> |
List-Archive: | <http://sourceware.org/ml/cygwin/> |
List-Post: | <mailto:cygwin AT cygwin DOT com> |
List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs> |
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 <corinna-cygwin AT cygwin DOT com> |
To: | cygwin AT cygwin DOT com |
Cc: | "Canham, Timothy K (348C)" <timothy DOT k DOT canham AT jpl DOT nasa DOT gov> |
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)" <timothy DOT k DOT canham AT jpl DOT nasa DOT gov> |
References: | <E8EB3633A6A4594CA063A3FCBC82C18C3621F0F6 AT ap-embx-sp40 DOT RES DOT AD DOT JPL> <20160420105016 DOT GB26118 AT calimero DOT vinschen DOT de> <E8EB3633A6A4594CA063A3FCBC82C18C3621FDE3 AT ap-embx-sp40 DOT RES DOT AD DOT JPL> |
MIME-Version: | 1.0 |
In-Reply-To: | <E8EB3633A6A4594CA063A3FCBC82C18C3621FDE3@ap-embx-sp40.RES.AD.JPL> |
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--
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |