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=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Thu, 7 Aug 2014 14:51:37 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: (call-process ...) hangs in emacs
Message-ID: <20140807125137.GV13601@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <20140801133225.GD25860@calimero.vinschen.de> <53DEDBBA.20102@cornell.edu> <20140804080034.GA2578@calimero.vinschen.de> <53DF8BDC.8090104@cornell.edu> <20140804134526.GK2578@calimero.vinschen.de> <53E0CC2D.4080305@cornell.edu> <20140805135830.GA9994@calimero.vinschen.de> <53E11A93.9070800@cornell.edu> <20140805184047.GC13601@calimero.vinschen.de> <53E3685B.8050508@cornell.edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="BnCwdHgQ2ZomtW9r"
Content-Disposition: inline
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@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@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@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--