Re: gtk2 using SysV memory? (Was: Re: [ITP] gvim-6.4)
Yaakov schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerrit P. Haase wrote: It is uploaded now, could you test, please? WFM. OT, but does this include the gdk-pixbuf security fix as well? Yes. Gerrit -- =^..^=
Re: gtk2 using SysV memory? (Was: Re: [ITP] gvim-6.4)
On Dec 27 23:15, Gerrit P. Haase wrote: Yaakov schrieb: So what we have here looks like something I don't like, which is, that running gvim requires to run Cygserver because something, gvim itself or some library, is using SYSV shared memory. After doing some experimentation, it looks like this isn't a specific problem with gvim, but is common to gtk2 apps, e.g.: $ CYGWIN= gcolor2 Bad system call $ gcolor2 [runs] I don't think that should be necessary, except in very trying cases like, say, a database like postgresql. So, whatever is using SYSV shared memory in this scenario, it shouldn't. The fact that I can start gvim on local Xmingw server but not on a remote X server shows, that SYSV shared memory can't be a necessity. Gerrit? It is uploaded now, could you test, please? gvim works fine now w/o SYSV shared memory, even on my remote X terminal. Thank you! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gtk2 using SysV memory? (Was: Re: [ITP] gvim-6.4)
Yaakov schrieb: So what we have here looks like something I don't like, which is, that running gvim requires to run Cygserver because something, gvim itself or some library, is using SYSV shared memory. After doing some experimentation, it looks like this isn't a specific problem with gvim, but is common to gtk2 apps, e.g.: $ CYGWIN= gcolor2 Bad system call $ gcolor2 [runs] I don't think that should be necessary, except in very trying cases like, say, a database like postgresql. So, whatever is using SYSV shared memory in this scenario, it shouldn't. The fact that I can start gvim on local Xmingw server but not on a remote X server shows, that SYSV shared memory can't be a necessity. Gerrit? It is uploaded now, could you test, please? Gerrit -- =^..^=
Re: gtk2 using SysV memory? (Was: Re: [ITP] gvim-6.4)
Gerrit P. Haase wrote: Yaakov S (Cygwin Ports) wrote: After doing some experimentation, it looks like this isn't a specific problem with gvim, but is common to gtk2 apps, e.g.: $ CYGWIN= gcolor2 Bad system call $ gcolor2 [runs] I don't think that should be necessary, except in very trying cases like, say, a database like postgresql. So, whatever is using SYSV shared memory in this scenario, it shouldn't. The fact that I can start gvim on local Xmingw server but not on a remote X server shows, that SYSV shared memory can't be a necessity. Gerrit? Yes maybe, need to take a look at the configure and build logs though. Yes, --enable-shm is default=yes. I rebuild now the pending 2.6.10 release with --enable-shm=no and upload later this day. Gerrit -- =^..^=
Re: gtk2 using SysV memory? (Was: Re: [ITP] gvim-6.4)
Yaakov S (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Corinna Vinschen wrote: The error message you see points to the fact that apparently some part of gvim or subsequent libraries use SYSV shared memory. The reason you see this error message and I see a SIGSYS is that I don't have CYGWIN=server set in my environment by default and no cygserver is running unless I'm debugging it. OK, I see this now as well locally, if I unset CYGWIN. So what we have here looks like something I don't like, which is, that running gvim requires to run Cygserver because something, gvim itself or some library, is using SYSV shared memory. After doing some experimentation, it looks like this isn't a specific problem with gvim, but is common to gtk2 apps, e.g.: $ CYGWIN= gcolor2 Bad system call $ gcolor2 [runs] I don't think that should be necessary, except in very trying cases like, say, a database like postgresql. So, whatever is using SYSV shared memory in this scenario, it shouldn't. The fact that I can start gvim on local Xmingw server but not on a remote X server shows, that SYSV shared memory can't be a necessity. Gerrit? Yes maybe, need to take a look at the configure and build logs though. Gerrit -- =^..^=