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=pvLtyosW+gXNtzwqsGYT1KM6hiPXuLJbap0Kp5WNlpH0xXOavF2Fg
	XTAcK38TqQENxDSdgr+hIzCJtl3JDGuaXqY+xJs2GB3ui680hUmntMCmzMsUnjWt
	bAdFma1iEWfw4vKfXrSTMLWFSJRbyNubv8JFo8ztp1zJT4vN+fCOP8=
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=STzQhpvLgCXvSntAUpIfLc+vj/c=; b=hJ0iQKflWI8N2MNPbTipAYkaD214
	ugrDaS7aQnAPYYcp1dzncfiVWAnaBY62wTxsxUwaOnLQl+TMacvnH050fPwNiI1g
	78YEbjx9sga3uPFQQu3jk7mtEvhICbtwNKjlVGGyTpJq2oaVPs4qOiFWlDfqZrEU
	gOeNmyuPsfGzDMk=
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=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO: calimero.vinschen.de
Date: Tue, 5 Aug 2014 20:40:47 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: (call-process ...) hangs in emacs
Message-ID: <20140805184047.GC13601@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <53DB8D23 DOT 7060806 AT alice DOT it> <CAK9Gx1cjj-7cDP7CunD7Bxz35L+SU9+4Ro3HRot5cwjcArudOA AT mail DOT gmail DOT com> <20140801133225 DOT GD25860 AT calimero DOT vinschen DOT de> <53DEDBBA DOT 20102 AT cornell DOT edu> <20140804080034 DOT GA2578 AT calimero DOT vinschen DOT de> <53DF8BDC DOT 8090104 AT cornell DOT edu> <20140804134526 DOT GK2578 AT calimero DOT vinschen DOT de> <53E0CC2D DOT 4080305 AT cornell DOT edu> <20140805135830 DOT GA9994 AT calimero DOT vinschen DOT de> <53E11A93 DOT 9070800 AT cornell DOT edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="+nBD6E3TurpgldQp"
Content-Disposition: inline
In-Reply-To: <53E11A93.9070800@cornell.edu>
User-Agent: Mutt/1.5.23 (2014-03-12)

--+nBD6E3TurpgldQp
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Ken,

On Aug  5 13:55, Ken Brown wrote:
> On 8/5/2014 9:58 AM, Corinna Vinschen wrote:
> >On Aug  5 08:21, Ken Brown wrote:
> >>=3D=3D=3D modified file 'src/gmalloc.c'
> >>--- src/gmalloc.c       2014-03-04 19:02:49 +0000
> >>+++ src/gmalloc.c       2014-08-05 01:35:38 +0000
> >>@@ -490,8 +490,8 @@
> >>  }
> >>
> >>  #ifdef USE_PTHREAD
> >>-pthread_mutex_t _malloc_mutex =3D PTHREAD_MUTEX_INITIALIZER;
> >>-pthread_mutex_t _aligned_blocks_mutex =3D PTHREAD_MUTEX_INITIALIZER;
> >>+pthread_mutex_t _malloc_mutex;
> >>+pthread_mutex_t _aligned_blocks_mutex;
> >>  int _malloc_thread_enabled_p;
> >>
> >>  static void
> >>@@ -526,8 +526,11 @@
> >>       initialized mutexes when they are used first.  To avoid such a
> >>       situation, we initialize mutexes here while their use is
> >>       disabled in malloc etc.  */
> >>-  pthread_mutex_init (&_malloc_mutex, NULL);
> >>-  pthread_mutex_init (&_aligned_blocks_mutex, NULL);
> >>+  pthread_mutexattr_t attr1, attr2;
> >>+  pthread_mutexattr_settype (&attr1, PTHREAD_MUTEX_NORMAL);
> >>+  pthread_mutexattr_settype (&attr2, PTHREAD_MUTEX_NORMAL);
> >>+  pthread_mutex_init (&_malloc_mutex, &attr1);
> >>+  pthread_mutex_init (&_aligned_blocks_mutex, &attr2);
> >>    pthread_atfork (malloc_atfork_handler_prepare,
> >>                   malloc_atfork_handler_parent,
> >>                   malloc_atfork_handler_child);
> >>
> >>
> >>The first hunk avoids the double initialization, but I don't understand=
 why
> >>the second hunk does anything.  Since PTHREAD_MUTEX_NORMAL is now the
> >>default, shouldn't calling pthread_mutex_init with NULL second argument=
 be
> >>equivalent to my calls to pthread_mutexattr_settype?  Does this indicat=
e a
> >>Cygwin bug, or am I misunderstanding something?
> >
> >AFAICS you're missing something.  Your pthread_mutexattr_t attr1, attr2
> >are not initialized.  They contain some random values, thus they are not
> >good objects.  The calls to pthread_mutexattr_settype as well as the
> >calls to pthread_mutex_init will fail with EINVAL, but you won't see it
> >due to missing error handling, and you end up without mutexes at all.
> >If you call pthread_mutexattr_init before calling
> >pthread_mutexattr_settype the situation shoul;d be the same as before.
>=20
> Thanks for catching my mistake.  Your earlier suggestion about explicitly
> setting the pthread_mutexes to be ERRORCHECK mutexes seems to fix the
> problem (as long as I remember to call pthread_mutexattr_init).  The revi=
sed
> patch is attached.  I went back to using both the static and dynamic
> initializations as in the original code, since you said that's harmless.

I'm glad to read that, but I'm still a little bit concerned.  If your
code works with ERRORCHECK mutexes but hangs with NORMAL mutexes, you
*might* miss an error case.

I'd suggest to tweak the pthread_mutex_lock/unlock calls and log the
threads calling it.  It looks like the same thread calls malloc from
malloc for some reason and it might be interesting to learn how that
happens and if it's really ok in this scenario, because it seems to
be unexpected by the code.


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--+nBD6E3TurpgldQp
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJT4SUvAAoJEPU2Bp2uRE+gsFgP/ArWRxfP1/qPWCtE1FfBBuce
Q5TAFWtD7yk9JSv+CUE73zxDOtSoxiUwDURPnyXpz12gvM0KtGYdBe+Q+W8QyOSQ
rlSV11DSQv1mw+jZWOTp+xNlRszenM0Ry5PlBOxmSn3DzLg10pw73H6OFubYexn1
SHr6o8GLvFlTXfh0dx/lktp61YZewIjiFcNZ4MhRorZ9JmNJx+DYq0bSj52JQr93
5SYL7iwJ3xApws9MUgaFjTO3NtJ5GsU+8g5mV9BcHiA37ZHRb/uDElDG5mafZYZF
z07PFCqGn+9tBsiQzDpSdSa5EaqM3OoPOyB2OW7JVT4m+glFR1C89M1piSOjwn5K
fXgxxdG3dQ4foxz+ztlHCQlFQoLsggJCieLVEdygcxcmJmahMVWuYW9yAPYDf59e
kHCKGmr1Tlf/3q2m1ON+he3/i7KGXCj9pLb/HzA0NxKwsxKtpuIyNcBdARvq6h1F
4hy28WFw8B3sMXG4UxNyHAxOxaja2jipIxlylMUvtpxOaK1My3gfEQ9zYqM+8F8/
4Gd6Ix5ndxy8eY2XwBmGGci3uSd+TpoT1ZB773l2nDwQtHmAtyDEN0XbfJCprXt5
SaVEdQKSckIf2J0DKc/QwS4JTOZl1lGaOFDwVb/Cn0zBtlp6cIgGpXRvL/VIbujf
HqVLxfWazv0EdS2jSGAf
=09Pv
-----END PGP SIGNATURE-----

--+nBD6E3TurpgldQp--