public inbox for
help / color / mirror / Atom feed
From: Ryan Johnson <>
To: Jon TURNEY <>
Subject: Re: Still can't run XServer or any apps that require it
Date: Sat, 07 May 2011 11:51:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2:59 PM, Jon TURNEY wrote:
> Looking into this a bit more, it's not quite clear what's going on here:
> There's a few failure modes which can be reported as "XKB: Could not invoke
> xkbcomp", but the assumption that this is a fork() failure seems likely, given
> that the problem can be made to go away by rebasing.
> But I think that, at the point which fork() is invoked, XWin hasn't loaded any
> DLLs yet, so the fork() failure shouldn't be due to an inability to remap DLLs
> in the child to the same address as the parent.
The address space layout randomization feature as implemented in 
Win7-x64 (and probably Vista/x86 as well) means that *any* dll can fail 
to map to the same address as its parent. Often it's the parent that's 
messed up, which means no subsequent fork() is likely to succeed.

That's why the problem comes in spurts: if you get a good parent, where 
nothing got pushed around the wrong way, fork() will eventually succeed 
thanks to Win7's feature which restarts crashed processes automatically 
(essentially retrying the fork until a "good" child arrives). If you get 
a bad parent, though, the chances of getting a compatibly bad child are 
pretty low. I see this a lot in emacs; Windows usually gives up after 
5-6 crashes in a row.

Enabling the tsaware bit for every dll should also help (see docs for 
peflagsall), because Windows will at least do its best to not clobber 
any dll with any other dll, but it still doesn't prevent a random thread 
stack or heap placement from pushing a dll out of its way.

>>>>> [1]
>>>> Also, I've found that using a different base address with rebaseall
>>>> seems to help with some X problems:
>>>> dash -c "rebaseall -b 0x77000000"
>>> Ok, that appears to have fixed my problem. Is that a "permanent" fix?
>> For now, yes. ;-)
> Humour-impaired persons, please note smiley
AFAICT, that's actually a 100% accurate description of rebaseall. The 
"fix"will last until the next time Windows hands you a badly laid-out 
parent process (transient problem, just restart the parent), or until 
the next run of cygwin setup replaces rebased dlls with 
newer-but-not-rebased versions (permanent, have to re-rebaseall).


Unsubscribe info:
Problem reports:

  reply	other threads:[~2011-05-02 14:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-23 16:47 David M. Karr
2011-04-25 15:23 ` Jon TURNEY
2011-04-25 17:07   ` Christopher Faylor
2011-04-26  5:16     ` David M. Karr
2011-04-26 15:37       ` Larry Hall (Cygwin-X)
2011-04-28 13:25         ` Jon TURNEY
2011-05-07 11:51           ` Ryan Johnson [this message]
2011-04-26  1:32   ` David M. Karr

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