Mail Archives: cygwin/2014/08/05/09:58:58
--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--
- Raw text -