[64bit] Problem with emacs and shared memory under X11

Corinna Vinschen corinna-cygwin@cygwin.com
Thu Jul 18 21:35:00 GMT 2013


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



More information about the Cygwin-apps mailing list