This is the mail archive of the
mailing list for the Cygwin project.
Re: [64bit] Problem with emacs and shared memory under X11
- From: Ken Brown <kbrown at cornell dot edu>
- To: cygwin-apps at cygwin dot com
- Date: Fri, 19 Jul 2013 12:04:04 -0400
- Subject: Re: [64bit] Problem with emacs and shared memory under X11
- References: <51D803A0 dot 7090700 at cornell dot edu> <51D82992 dot 5010402 at dronecode dot org dot uk> <51E70D37 dot 5020600 at dronecode dot org dot uk> <20130718083748 dot GA9628 at calimero dot vinschen dot de> <51E858E2 dot 7050802 at dronecode dot org dot uk> <20130718213455 dot GC30542 at calimero dot vinschen dot de> <51E91378 dot 6060402 at dronecode dot org dot uk> <20130719113509 dot GF20871 at calimero dot vinschen dot de>
On 7/19/2013 7:35 AM, Corinna Vinschen wrote:
On Jul 19 11:22, Jon TURNEY wrote:
On 18/07/2013 22:34, Corinna Vinschen wrote:
On Jul 18 22:06, Jon TURNEY wrote:
On 18/07/2013 09:37, Corinna Vinschen wrote:
On Jul 17 22:31, Jon TURNEY wrote:
After going around in circles on this a few times, this is what I now think I
The proximate cause of this error is that the x86_64 libcairo2 package appears
to be built with IPC_RMID_DEFERRED_RELEASE defined, which should only happen
on systems which allow processes to shmat() to a shared memory segment which
has already been marked for deletion with shmctl(IPC_RMID) (A non-portable
(This behaviour can be turned on in cygwin by setting the
'kern.ipc.shm_allow_removed' to 'yes' in /etc/cygserver.conf, so that is also
a work around)
Attached is the configure test extracted from cairo, which for some reason
functions incorrectly on x86_64.
I'm glad to read it's not a bug in Cygwin or Cygserver :}
I'm a bit confused to read that you don't consider this shmtest.c behaving
incorrectly on x86_64 a bug in Cygwin.
I totally misunderstood your mail apparently. Your mail implied to me
that this is a build error in libcairo2, not in Cygwin, so I thought
Cygwin is off the hook.
Sorry, I should have explained more clearly that a SHM bug in cygwin could
cause an incorrect result for a configure test in cairo, which causes cairo to
be built wrongly, which causes applications which use it to fail with SHM errors.
No worries, after you clarified, pieces fell into place :)
Thanks for tracking this down and the patch. I'm just wondering. This
is one of those subtil bugs introduced by the size difference between
int and pointers. Maybe we should better provide a constructor which
takes an ssize_t as input, rather than an int. Does the below fix the
problem as well?
Oh yes, that works, and is a bit clearer.
Thanks for testing. I applied the patch and attributed it to you in
the ChangeLog since you did all the work anyway.
There's still the x86 issue that I mentioned earlier. With
cygwin-1.7.21 (as well as today's snapshot), I'm getting a return value
of 0 from shmtest on x86. This is with cygserver not running. (In
fact, cygserver has never been configured on this system, so there's no
/etc/cygserver.conf). Jon reported getting a return value of 1 using