This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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
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.

$ uname -a
CYGWIN_NT-5.1 byron 1.7.20(0.266/5/3) 2013-06-07 11:11 i686 Cygwin

$ ./shmtest ; echo $?
1

$ uname -a
CYGWIN_NT-6.1 allegra 1.7.21(0.267/5/3) 2013-07-15 13:50 x86_64 Cygwin

$ ./shmtest ; echo $?
0

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.

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 build.

Ken


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]