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=CVSF/6I7LRgBchA4/nzZ7bCcWlxovb6r6CdY6pb4yK4wpPprq00Qz
	WRAxqwkf5O56MdY5escaRhOP7FvikDd6DWz/G10DtOSXmEn4pUncJW5/j8UawIHo
	GbmbZaXLqFD2CWr0D8paOURTErooXz6hecJU7SKSE4nQ3v8J/DSB1Q=
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=lrQDAuDdiTrLy55mpsnBGiYrYr4=; b=XCTQ1fWBTDef80NwLVujFVWLXvUh
	VOM4o9qmBUf8rH4IzbjDqVubI20hcHEVvRtpUbbXNODx9DXxFi+duCTQSj8Buzx8
	RKbWeyFKd8ANOL8phsfaUjor/1DXdncmM+euDNrnDFmSppzFChf64ZkAssBuylDR
	ErMhQJ3IhcYfddM=
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 15:58:30 +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: <20140805135830.GA9994@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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk"
Content-Disposition: inline
In-Reply-To: <53E0CC2D.4080305@cornell.edu>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Aug  5 08:21, Ken Brown wrote:
> On 8/4/2014 9:45 AM, Corinna Vinschen wrote:
> >...this, and the fact that fork/exec (vfork =3D=3D fork on Cygwin) still
> >works nicely in other scenarios points to some problem with the usage of
> >pthread_mutexes in the application may be the culprit.
> >
> >For instance, is it possible that emacs expects the pthread_mutexes
> >in malloc to be ERRORCHECK mutexes?  What if you explicitely set
> >them to ERRORCHECK at creation time?
>=20
> That doesn't seem to be the issue, but I think I did find the problem, and
> it looks like there might be both an emacs bug and a Cygwin bug. Here's t=
he
> relevant code from emacs's gmalloc.c:
>=20
> pthread_mutex_t _malloc_mutex =3D PTHREAD_MUTEX_INITIALIZER;
> pthread_mutex_t _aligned_blocks_mutex =3D PTHREAD_MUTEX_INITIALIZER;
>=20
> [...]
>=20
>   /* Some pthread implementations call malloc for statically
>      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);
>=20
>=20
> The pthread_mutexes are initialized twice, resulting in undefined behavior
> according to Posix.  That's the emacs bug.

That's not the problem.  It's not necessary to call pthread_mutex_init
on statically initialized mutexes, but it doesn't hurt either.  Only
when calling pthread_mutex_init twice on the same object it goes
downhill, especially when the first incarnation of the mutex was already
locked.

> But simply removing the static
> initialization doesn't fix the problem.  On the other hand, the following
> patch does seem to fix it, at least in preliminary testing:
>=20
> =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 @@
>  }
>=20
>  #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;
>=20
>  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);
>=20
>=20
> The first hunk avoids the double initialization, but I don't understand w=
hy
> 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 indicate 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.


Corinna

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

--UugvWAfsgieZRqgk
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJT4OMGAAoJEPU2Bp2uRE+g/mAP/0vWdrhdlGzw5fyfj9VjesvH
Nkb4gVUQGESj6Ow7goQSkH3RLtgElEcSAlDuSHW+x7/Ne2pB1wnQi5SE1tUdmEM4
Q9g4DTwPLs/lic8QifXaaTPCawneSjnhQhDKr0usf4TENb52ggJSDNOu2mh6oFEL
fTrdF9CYN724uE7+qLOWDzs3c0oukiZhgvt7U5woTDH+QZeodjw62h4OuPxIkSfG
QsNCN9IAPpdt8KFKE8XLDOcu+MvbX2ytCWTD4lMRWpY5LFCuVdPJ3U8VOvu5pS0J
fHwKGUQzBLry/dqkbkgKVqnHLulpxItjUMTwvVxqCaQtc2q1Z+L6LBJh1qunzoXL
wl+rbmKEeFWjhiyUHE8v/vcDGqQOAYC+t+M3+BULabvh+5YN2YAvhEpy/iOd/Z10
Yf+GyjZTLPOetd4FLpQLCuSANGrrUmaE/zonLaB9B2TdpztepcT1s3VFZq8WQPh8
R+Qgql7FDyaAzBoaapiZOck+jnzQnUURRxzFvjpF62P4fIa5Li+CjV068Ew3tv5z
iBRxDxwexJq7x0/vSICR+x8fKvonYewRZj2eXYXaq50Ty7E0SQoys4pnd+kKIqhB
pu/wPj4N83NK4tc1DwNC6cPpvCWoG5BGSIro+X0dImvMH9NE8+bFGHqxP7kibueI
GsgjRuR+ER5H0ZxAEO20
=Yvnd
-----END PGP SIGNATURE-----

--UugvWAfsgieZRqgk--