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 Jul 19 11:22, Jon TURNEY wrote:
> On 18/07/2013 22:34, Corinna Vinschen wrote:
> > 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.
> 
> Sorry, I should have explained more clearly that a SHM bug in cygwin could
> cause an incorrect result for a configure test in cairo, which causes cairo to
> be built wrongly, which causes applications which use it to fail with SHM errors.

No worries, after you clarified, pieces fell into place :)

> > 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?
> 
> Oh yes, that works, and is a bit clearer.

Thanks for testing.  I applied the patch and attributed it to you in
the ChangeLog since you did all the work anyway.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat


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