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

[Jon TURNEY <jon dot turney at dronecode dot org dot uk>]

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.

Attachment: cygserver_ipc.h.patch
Description: Text document