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:subject:message-id:reply-to | |
:references:mime-version:content-type:in-reply-to; q=dns; s= | |
default; b=WnU9J7Qef6AYlZIm73E0sfsmRrF9NTZhPeGOeKhEg0CT37ltnJwgV | |
/9cvaLosG9gj8GCAFim9q2MtMUxrzPqlIE4wGBeEwEPYN+XzTxT3m2Hapgr4HKMu | |
bjm0BsOvq8yqp6wgI7tkpvdmAZvExzs9nclKlFfm831L6u4HK1f29c= | |
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:subject:message-id:reply-to | |
:references:mime-version:content-type:in-reply-to; s=default; | |
bh=u0QOPlWv5wXhM5ifFB6hL32wgIM=; b=w5iew8Rr1lkLZtbyIF5tUuj1rF06 | |
0KwyDpkBa2m1nmVE8VOzxQRlGbqlmOe1mx9WDwp2OsICKmnY14oFdH24lofm5eOy | |
x5oJzkFRT5DIXGlDuOPOYygmJ/nF1rk36cSSy9ug9GhAAaWkk103KcgySlIbgV/V | |
KtcuU5iOyPTh5M8= | |
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.5 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_PBL,RDNS_DYNAMIC autolearn=ham version=3.3.2 spammy=incurred, Kevin, occasionally, hangs |
X-HELO: | calimero.vinschen.de |
Date: | Tue, 24 May 2016 12:20:57 +0200 |
From: | Corinna Vinschen <corinna-cygwin AT cygwin DOT com> |
To: | cygwin AT cygwin DOT com |
Subject: | Re: spinlock.h timeout causing *** fatal error - add_item abort |
Message-ID: | <20160524102057.GB32753@calimero.vinschen.de> |
Reply-To: | cygwin AT cygwin DOT com |
Mail-Followup-To: | cygwin AT cygwin DOT com |
References: | <D348D3EA.10AEB%knomura AT vmware DOT com> |
MIME-Version: | 1.0 |
In-Reply-To: | <D348D3EA.10AEB%knomura@vmware.com> |
User-Agent: | Mutt/1.6.1 (2016-04-27) |
--rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Apr 29 16:03, Kevin Nomura wrote: > Hi, >=20 > We occasionally see an api_fatal abort during process startup like: >=20 > *** fatal error - add_item ("somepath", "/", ...) failed, errno 1 >=20 > This happens if mountinfo.init(false) in user_info::initialize is > called twice. The error occurs on a second call when trying to add > the root mount point when it already exists. >=20 > mountinfo.init is guarded by a "spinlock" object that should only > allow one process to call it. But the spinlock has a timeout. After > 15 seconds, it stops waiting and returns a value of 0. The fatal > error can occur if two processes are starting around the same time > and the first process takes a long time in internal_getpwsid(). We've > seen this happen in our environment due to LDAP queries taking a long > time. (Incidentally we are using msys, but code in spinlock.h and > shared.cc looks the same in cygwin). >=20 > To solve the aborts it is tempting to make a local fix to remove the > spinlock timeout. I assume there was a rationale for it, and would > like to understand what tradeoff is incurred if we remove it. Actually I can't tell you. You might just want to try it and see if it has some weird side-effect. The problem this *probably* was supposed to handle is that some process hangs in the initialization indefinitely, thus blocking out other processes. 15 secs is just some arbitrary big value. The original reason to use a spinlock here wasbased on the idea that reading fstabs and passwd/group files is quick, thus a spinlock is the least intrusive locking mechanism. This is obviously not true anymore, now that fetching the user info may require network access. I put an item on my TODO list to revisit this code and introduce another, more reliable locking here. For the time being you might want to try a spinlock with a longer timeout (2 mins, perhaps) Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --rS8CxjVDS/+yyDmU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXRCsJAAoJEPU2Bp2uRE+giWkP/RYTMKlUqddhS3+5YfDC/cxQ dG8dhkoD5+iVcDY1Io8DgQsr06MHcFoyKqSrONovbLO2QD/pZDbE5lBcxt5vBX6w qElBoepKiHGtntVrtaDa3InI2zD1Vae/4nka9pOKRIK1j3tVTHCIRaf6j2NRrfmU yBcn4nBe4En/swiLH1rD1cRVCq28wV3wyzj9ZJysnOpU6bFFEOXI1uzyjzFMo19e Fh/4C7n8doQHQ4irx9arhfzb7ifP5habeATDG5a8Img0bIshy7nvfUDK/uh3Eo1T 0XDm9x13hnJEX9HuNIbxVKtxVcxYXrlCVjHfu5nybNeO1eQw/6eXj+rrUw868et8 49pf5K+GOGk2pmU2ED3tqWwPeyJ4XCK5Nrf2LH+skE7VwU1pr3wFhPgaMfrevfIf VS9UlsxQE1BE7pKSFZuKDZr33Em6JYCvxoJMDuW3J0UoMmu8N32v7ut/DXLeKPUB IdAScnb1QdJc85vxHO/N6klY0/7fQOcvqpeylLORUV7ocXKUcYYoSyze4QBKnbWV pTA2ppiLlLpO18Epkm1YtAVFx+DBg+A8L9084fdKs3yGsRqt3VwYVzszPqTvBLpi 7vO+ebAqsrT18dv/MvQOckZhV64Z0RCLpQUjdXzJ27pVIFsZnhdIO8Bfq9zzfoza +vxqOT9P3YZMEDWbScfO =ZO/p -----END PGP SIGNATURE----- --rS8CxjVDS/+yyDmU--
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |