Mail Archives: cygwin/2014/08/05/14:41:17
--+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--
- Raw text -