From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98256 invoked by alias); 3 Mar 2015 14:49:10 -0000 Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Reply-To: cygwin-xfree@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com Received: (qmail 98241 invoked by uid 89); 3 Mar 2015 14:49:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: out1-smtp.messagingengine.com Received: from out1-smtp.messagingengine.com (HELO out1-smtp.messagingengine.com) (66.111.4.25) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 03 Mar 2015 14:49:07 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8B1EB207D7 for ; Tue, 3 Mar 2015 09:49:04 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 03 Mar 2015 09:49:05 -0500 Received: from [192.168.1.102] (unknown [31.51.205.191]) by mail.messagingengine.com (Postfix) with ESMTPA id 42F1AC00295 for ; Tue, 3 Mar 2015 09:49:05 -0500 (EST) Message-ID: <54F5C9DA.2040703@dronecode.org.uk> Date: Tue, 03 Mar 2015 14:49:00 -0000 From: Jon TURNEY User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: cygwin-xfree@cygwin.com Subject: Re: Cannot run Qt5 applications. References: <54D2A922.3060507@tiscali.co.uk> <54D2CA12.5080701@dronecode.org.uk> <54DE4334.9060101@dronecode.org.uk> <1425339264.7292.8.camel@cygwin.com> <20150303090407.GA31622@calimero.vinschen.de> In-Reply-To: <20150303090407.GA31622@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00005.txt.bz2 On 03/03/2015 09:04, Corinna Vinschen wrote: > On Mar 2 17:34, Yaakov Selkowitz wrote: >> On Fri, 2015-02-13 at 18:32 +0000, Jon TURNEY wrote: >>> On 05/02/2015 01:40, Jon TURNEY wrote: >>>> On 04/02/2015 23:20, David Stacey wrote: >>>>> I'm having difficulty running any Qt5 application. These are the >>>>> commands I'm issuing: >>>>> [snip] >>>>> and I see the clock, so X is up and running. Then: >>>>> [snip] >>>> >>>> Possibly you need to install and start cygserver (See [1]) >>>> >>>> If so, this is because Qt5 is assuming shared memory is available, which >>>> could possibly be handled in a better way... >>> >>> This looks like a portability problem in Qt5, where it only handles >>> shmget() failing with a return value of -1, not with SIGSYS, to fallback >>> to using an image in unshared memory. >>> >>> Patch attached. >> >> Or is it a problem with our shmget()? >> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/shmget.html >> http://man7.org/linux/man-pages/man2/shmget.2.html >> >> Perhaps we should be just returning -1 with an errno (ENOSYS?) instead >> of raise(SIGSYS)? I think it was a BSD-ism to raise SIGSYS if shared memory is not available due to policy. Historically, there must have been some OS which did this, because there is code to detect this situation in the X server [1] [1] http://cgit.freedesktop.org/xorg/xserver/tree/Xext/shm.c#n167 Looking at [2],[3] it seems perhaps this was added in Cygwin because some FreeBSD test code was used? [2] https://cygwin.com/ml/cygwin-cvs/2003-q4/msg00130.html [3] https://cygwin.com/ml/cygwin-cvs/2003-q4/msg00128.html I'd kind of assumed that modern BSDs behave in the same way, but that doesn't actually seem likely. I have absolutely no problem with changing this to return ENOSPC (there is a limit of 0 SHM identifiers, and we have reached it), or whatever is appropriate in this state. > Or you just add signal(SIGSYS, SIG_IGN) prior to calling shmget. > SIGSYS is raised when calling a system call which isn't available. > That's perfectly valid. This is true. I guess it's not how Linux behaves, though, so I think changing it ought to be considered to minimize porting effort. I'll also note that checking once at startup, as the X server does, is not enough. If the cygserver is stopped, it will die with an unexpected SIGSYS when a client tried to use shared memory. > Of course, it would be nice if Qt5 used POSIX shared memory objects > instead, but that's asked too much, probably. Unfortunately, it has to use whatever the X server's MIT-SHM extension uses... -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/