This is the mail archive of the
mailing list for the Cygwin project.
Re: [64bit] Problem with emacs and shared memory under X11
- From: Jon TURNEY <jon dot turney at dronecode dot org dot uk>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 18 Jul 2013 22:22:38 +0100
- 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> <51E84910 dot 6000505 at cornell dot edu>
On 18/07/2013 20:59, Ken Brown wrote:
> On 7/17/2013 5:31 PM, 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
>> 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
>>>> 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
>>> 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
>> 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
>> 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.
>>> $ uname -a
>>> CYGWIN_NT-5.1 byron 1.7.20(0.266/5/3) 2013-06-07 11:11 i686 Cygwin
>>> $ ./shmtest ; echo $?
>>> $ uname -a
>>> CYGWIN_NT-6.1 allegra 1.7.21(0.267/5/3) 2013-07-15 13:50 x86_64 Cygwin
>>> $ ./shmtest ; echo $?
Sorry, I obviously didn't explain the issue very clearly here, as there has
been some confusion.
> You tested cygwin-1.7.20 on x86 but cygwin-1.7.21 on x86_64. I'm getting a
> return value of 0 with cygwin-1.7.21 on both x86 and x86_64. But I have to
> have cygserver running in the x86_64 case; otherwise I get "Bad system call
> (core dumped)" and a return value of 140.
Unless 'kern.ipc.shm_allow_removed' is set to 'yes', it is a bug in cygwin if
this test returns 0.
Such a bug definitely exists on x86_64.
> Did you have cygserver running when you did your tests? It doesn't seem good
> that the outcome of a configure test should depend on whether or not the
> person building the package happens to have cygserver running while doing the
Running this test when cygserver isn't running is safe. Testing if the shared
memory implementation has IPC_RMID_DEFERRED_RELEASE comes to the safe
conclusion that it doesn't, if shared memory isn't unavailable.
I agree that this configure test is slightly dangerous, but for different
reasons: if the test returns 0 (which should only happen if cygserver is
running, AND it is configured with 'kern.ipc.shm_allow_removed yes') then the
built libcairo will not work reliably on a system which has cygserver running,
but 'kern.ipc.shm_allow_removed no' (the default).
(That is, the test is written assuming that IPC_RMID_DEFERRED_RELEASE is fixed
property of a target)
The built cairo will work reliably on a system which doesn't have cygserver
running, or has an X server which as been started with '-extension MIT-SHM' to
disable use of shared memory, or is running on a different system from the X
server, as cairo contains fallbacks for the case when shared memory with the X
server is not available...