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=ad/Qcja0EVM7K6/nHglEbyXH38prdqvBSJLl6IhcpuC4gt9gLZlt3
	39HzoI2uvvJUAe+qeOJWD5uVbO3ilnVE7veZpooteFqHej6Vi70bRtYjX7EE/NP/
	ICbiAryUERE+0TfqR60OmaNe1IwXUpKnDUSEM09kW4ZNGSEX105tUo=
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=twtXax16aB7Ouvm6dHW6U+WfciQ=; b=PGDCCizz+o61mAA/KF6FZ0/rf6ki
	nb/z3bHu4Ic2lPF9sWHPUvwMUWRSfouI4d6PeSs3cgcQ9z8m+z3eNIk/fPiioZFk
	vEj2VW4JmplOz7wvjcLBI6p0Kl+4Q5+OIUD2oUUTAhkWST4qxI5V4shZ/BChTJDf
	a4r1Smhya4mS0kI=
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=-3.9 required=5.0 tests=AWL,BAYES_00,URIBL_BLACK autolearn=no version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Thu, 7 Aug 2014 14:51:37 +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:	<20140807125137.GV13601@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<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> <20140805184047 DOT GC13601 AT calimero DOT vinschen DOT de> <53E3685B DOT 8050508 AT cornell DOT edu>
MIME-Version:	1.0
In-Reply-To:	<53E3685B.8050508@cornell.edu>
User-Agent:	Mutt/1.5.23 (2014-03-12)

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

Hi Ken,

On Aug  7 07:51, Ken Brown wrote:
> Hi Corinna,
>=20
> On 8/5/2014 2:40 PM, Corinna Vinschen wrote:
> >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.
>=20
> I think I found the problem with NORMAL mutexes.  emacs calls pthread_atf=
ork
> after initializing the mutexes, and the resulting 'prepare' handler locks
> the mutexes.  (The parent and child handlers unlock them.)  So when emacs
> calls fork, the mutexes are locked, and shortly thereafter the Cygwin DLL
> calls calloc, leading to a deadlock. Here's a gdb backtrace showing the
> sequence of calls:

First question:  Why does emacs use its own malloc on Cygwin rather=20
than the system-provided one?  Is that really necessary?

> #0  malloc (size=3Dsize AT entry=3D40) at gmalloc.c:919
> #1  0x0053fc28 in calloc (nmemb=3D1, size=3D40) at gmalloc.c:1510
> #2  0x61082074 in calloc (nmemb=3D1, size=3D40)
>     at /usr/src/debug/cygwin-1.7.31-3/winsup/cygwin/malloc_wrapper.cc:100
> #3  0x61003177 in operator new (s=3Ds AT entry=3D40)
>     at /usr/src/debug/cygwin-1.7.31-3/winsup/cygwin/cxx.cc:23
> #4  0x610fc9d3 in pthread_mutex::init (mutex=3D0x61187d34 <reent_data+852=
>,
>     attr=3D0x0, initializer=3D0x12)
>     at /usr/src/debug/cygwin-1.7.31-3/winsup/cygwin/thread.cc:3118
> #5  0x610fcc13 in pthread_mutex_lock (mutex=3D0x61187d34 <reent_data+852>)
>     at /usr/src/debug/cygwin-1.7.31-3/winsup/cygwin/thread.cc:3170
> #6  0x611319d8 in __fp_lock (ptr=3D0x61187cd0 <reent_data+752>)

Right, __fp_lock needs a pthread lock and since this lock hasn't been
used yet, it has to create it.  The pthread_mutex creation calls the
new operator which in turn calls calloc.

>     at /usr/src/debug/cygwin-1.7.31-3/newlib/libc/stdio/findfp.c:287
> #7  0x61154f75 in _fwalk (ptr=3D0x28d544,
>     function=3Dfunction AT entry=3D0x611319c0 <__fp_lock>)
>     at /usr/src/debug/cygwin-1.7.31-3/newlib/libc/stdio/fwalk.c:50
> #8  0x61131dea in __fp_lock_all ()
>     at /usr/src/debug/cygwin-1.7.31-3/newlib/libc/stdio/findfp.c:307
> #9  0x610fa45e in pthread::atforkprepare ()
>     at /usr/src/debug/cygwin-1.7.31-3/winsup/cygwin/thread.cc:2031
> #10 0x61076292 in lock_pthread (this=3D<synthetic pointer>)
>     at /usr/src/debug/cygwin-1.7.31-3/winsup/cygwin/sigproc.h:137
> #11 hold_everything (x=3D<synthetic pointer>, this=3D<synthetic pointer>)
>     at /usr/src/debug/cygwin-1.7.31-3/winsup/cygwin/sigproc.h:169
> #12 fork () at /usr/src/debug/cygwin-1.7.31-3/winsup/cygwin/fork.cc:582
>=20
> Is there a better way to deal with this issue than using ERRORCHECK mutex=
es?

Did you check if you get an error from pthread_mutex_lock on the
second invocation of malloc?  Is it EDEADLK?  If so, you can
ignore the error, but if you want to go ahead without adding lots
of error checking you might be better off using a RECURSIVE mutex.


Corinna

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

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

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

iQIcBAEBAgAGBQJT43ZZAAoJEPU2Bp2uRE+gO64P+wRF2J53Atc3TKe6BDRW61OV
OaLLzMp3vIxcGzRAA2Svm6Q21lRgK9+R0C0lChkrTqvz45qyykC0pfqERzrGmN2n
8GSAbSr6IsX4jE+fBh1gFK10hM3ILSPB8VlJYg8AaIDspI87Bh3h6De87M3PKq3b
gug+d4SPFoP7V2CotA4zfAMEQ+KfP7m/JsycuwHH9FjVZtleW+Wd/IvwwY/qfPKi
LQTRtPiZZWFxROqJVqIzoEGG01SY9H2lxoW08wjKdCY0BUGPOMpTl7dhEfAvMD2k
OchL2zziNS7EtjkwFG8pA0zyJHOIDwx708y5V0kQ/PWK8GDUX8H7IQ3dkac3tycu
5jN3gRWTct6V7sK34WDHhOs9JEU/PuS82TfeRa+qJEYFLeA9/DuGjNLPOCvWkd7F
0SjgftIiCA0emfFVs34569687Nb9m0YFsQlBHZ+067m4TZuFOpmKNBGdR5EzZ8T9
eqKEBUf/p/Adz3e1XXeohhB0RTr6Er5j+r5ci8Z4q98QrC/R94iiYMPAHHz8f4Yh
BBwUEq7Jok7JbgQKo4hOzer37x72FSD8A7fu0WxtVPhqQeDJP8K/cnr/EsaMBf8t
QCCKoFrTsrGezFP+BPwP6fgTKy+W3HYDHG2ajHlIlxCyNY7+OeQ7edYDXCTryw8m
CdwBMlM0sPQ3+N268BU6
=94xo
-----END PGP SIGNATURE-----

--BnCwdHgQ2ZomtW9r--

- Raw text -