public inbox for
help / color / mirror / Atom feed
From: Jon TURNEY <>
Subject: Re: Cannot run Qt5 applications.
Date: Tue, 03 Mar 2015 14:49:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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()?
>> 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]


Looking at [2],[3] it seems perhaps this was added in Cygwin because 
some FreeBSD test code was used?


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 

Volunteer Cygwin/X X Server maintainer

Unsubscribe info:
Problem reports:

  reply	other threads:[~2015-03-03 14:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-04 23:20 David Stacey
2015-02-05  1:40 ` Jon TURNEY
2015-02-06 14:57   ` David Stacey
2015-02-13 18:32   ` Jon TURNEY
2015-03-02 23:34     ` Yaakov Selkowitz
2015-03-03  9:04       ` Corinna Vinschen
2015-03-03 14:49         ` Jon TURNEY [this message]
2015-03-03 17:11           ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).