This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [64bit] Problem with emacs and shared memory under X11
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 18 Jul 2013 23:34:55 +0200
- 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>
- Reply-to: cygwin-apps at cygwin dot com
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
> >> know:
> >>
> >> 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
> >> Linux behaviour)
> >>
> >> (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.
> Looking a bit deeper, the penproximate cause seems to be the initializer for
> the class ipc_retval members of struct thread in client_request_shm::serve
> (line 85 of cygserver/shm.cc)
>
> This initializes from the int 0, which on 64 bit doesn't fully initialize the
> anonymous union inside class ipc_retval.
>
> This is then copied into _parameter.out.ptr at line 117, with a potentially
> uninitialized top 32 bits (in the error case, where retval isn't modified)
>
> Note that client code for shmat() in cygwin/shm.cc, doesn't check the error
> code from cygserver, only that the returned pointer is NULL.
>
> Attached is a patch with a not very elegant fix, which makes shmtest return 1
> on x86-64, as it should. I'm sure a better one can be devised.
>
> Index: cygserver_ipc.h
> ===================================================================
> RCS file: /cvs/src/src/winsup/cygwin/cygserver_ipc.h,v
> retrieving revision 1.13
> diff -u -r1.13 cygserver_ipc.h
> --- cygserver_ipc.h 23 Apr 2013 09:44:31 -0000 1.13
> +++ cygserver_ipc.h 18 Jul 2013 21:02:21 -0000
> @@ -59,7 +59,7 @@
> };
>
> public:
> - ipc_retval (int ni) { i = ni; }
> + ipc_retval (int ni) { obj = 0; i = ni; }
>
> operator int () const { return i; }
> int operator = (int ni) { return i = ni; }
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?
Index: cygserver_ipc.h
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/cygserver_ipc.h,v
retrieving revision 1.13
diff -u -p -r1.13 cygserver_ipc.h
--- cygserver_ipc.h 23 Apr 2013 09:44:31 -0000 1.13
+++ cygserver_ipc.h 18 Jul 2013 21:33:58 -0000
@@ -59,7 +59,7 @@ private:
};
public:
- ipc_retval (int ni) { i = ni; }
+ ipc_retval (ssize_t nssz) { ssz = nssz; }
operator int () const { return i; }
int operator = (int ni) { return i = ni; }
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat