On 18/07/2013 09:37, Corinna Vinschen wrote: > On Jul 17 22:31, Jon TURNEY wrote: >> On 19/06/2013 23:39, Yaakov (Cygwin/X) wrote: >>> There appears to be a bug in the MIT-SHM extension with the 64-bit >>> xserver; both XWin and Xvfb have manifested this so far. The easiest way to >>> trigger this is to install gnome-themes-standard, add >>> gtk-theme-name="Adwaita" to your ~/.gtkrc-2.0, then start a GTK+2 program >>> (e.g. gtk-demo), but GTK+3 programs also show this. Starting the server >>> with -extension MIT-SHM, or using a 32-bit server even with MIT-SHM, works >>> fine. >> >> On 06/07/2013 15:28, Jon TURNEY wrote: >>> On 06/07/2013 12:46, Ken Brown wrote: >>>> On 64bit Cygwin, if I try to run emacs under X11 while cygserver is >>>> running, >>>> emacs fails to connect to the X server. The error message from the X >>>> server is >>>> >>>> BadShmSeg (invalid shared segment parameter) on protocol request 131 >>>> >>>> To reproduce: >>>> >>>> 1. Install the current version of emacs-X11 (24.3-4). >>>> >>>> 2. Start the (64bit) cygserver service. >>>> >>>> 3. Start the (64bit) X server, e.g., by typing "startxwin" in a Cygwin >>>> Terminal. >>>> >>>> 4. In the resulting xterm, try to start emacs: >>>> >>>> $ emacs-X11.exe -Q & >>>> >>>> The result is that emacs displays the error message above and then aborts. >>>> >>>> emacs-X11 works fine if the X server is started when cygserver is not >>>> running. >>> >>> Yup, there's some kind of bug which affects SHM use by the X server on >>> 64bit. >>> I am looking into it. >>> >>> You can also work around this by starting the X server with '-extension >>> MIT-SHM' >> >> 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. 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; }