X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Mon, 6 Feb 2012 12:17:42 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: extremely rarely fork errors: who occuppies the space?
Message-ID: <20120206111742.GB3949@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <loom DOT 20120206T073826-243 AT post DOT gmane DOT org> <20120206092301 DOT GB17284 AT calimero DOT vinschen DOT de> <loom DOT 20120206T103030-363 AT post DOT gmane DOT org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <loom.20120206T103030-363@post.gmane.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Feb  6 11:00, Heiko Elger wrote:
> Corinna Vinschen writes:
> 
> > > 
> > > Antivirus software is deinstalled, Windows defender is deactivated.
> > > Rebaseall and peflagsall were running.
> > 
> > YoU don't need to run peflags.  If you have set the ASLR flag, it could
> > be the culprit.  Try resetting it and, I think, reboot the machine.  As
> > far as I understand ASLR on Windows, it stores rebase addresses for DLLs
> > in a database and always uses the same values until reboot.
> > 
> Oops - I thought running rebaseall AND peflagsall is recommended on a win7/64 
> system?

No, that was a misunderstanding at one point.  I thought this has been
removed from the relevant docs.

> I just installed a full cygwin installation (without games/gnome/kde/audio) in 
> another directory (please note: no snapshot installed) and did the follwing 
> for testing how many dlls have ASLR bit set:
> 
> $find . -iname '*.dll' | xargs peflags -v 2>/dev/null | grep '+dynamicbase' | 
> wc -l
> 
> [fresh installation]
> 77 (is this OK?)
> 
> [old installation with peflagsall run]
> 1450
> 
> 1450 DLLs !!! so perhaps this is real problem.
> 
> But what's about the other possible problem: tsawareness?
> Should I set tsware for the DLLs - we always use remote desktop for connecting 
> to other windows machines - so tsware should be set?
> Is this correct?

Yes and no.  Only executables need this flag, it's ignored on DLLs.
And, gcc sets this flag by default since 4.3.4, so I think there's no
reason to use it anymore.  Latest gcc 4.5.x also sets the large address
awareness flag on executables.  Advantage of that flag:  You get an
extra 2 Gigs of VM per process starting at 0x80000000 on 64 bit systems.
Cygwin will put its application heap there, so you have more space in the
lower 2 Gigs for DLL rebasing.

> What's the best to reinstall our system, cause I really not know which dll 
> should have set dynamicbase or not?

None of it, actually.

> Use cygwin setup option REINSTALL or remove installation and INSTALL?

Just use peflags to remove the flag instead of reinstalling.  I'm not
sure if some DLLs have this flag set by default in the distro, and in
that case you're back to square one and have to run peflags anyway.

> > As for rebaseall, are you really sure?  You can inspect the values the
> > Cygwin DLLs are rebased to by running `rebase -s -i'.  If the output
> > contains asterisks after the base and size values of two adjacent DLLs,
> > they collide and need rebasing again.
> > 
> I know the new feature of rebase (nice feature) ...
> I checked this already - there are no asterisks.

Hmm, too bad.

> > For a start, you could use the shiny new /proc/$PID/maps functionality
> > on the parent shell.  If you have a shell which fails to fork and you
> > can get it to wait, then fetch the pid from ps and call `less
> > /proc/$PID/maps' and see what is at 0x6d000000.  If you want to stop
> > the child, you would have to build your own Cygwin DLL and add something
> > like a long Win32 Sleep() call after printing the above message in
> > child_info_fork::abort and then look into /proc/$PID/maps for that
> > process.
> > 
> 
> I know /proc/$PID/maps - nice feature too.
> 
> This sounds good, but is there a way doing this programatically - in an easy 
> way.
> Cause only delaying will not work - cause the error is runing on a remote 
> machine ...
> Or even prettier - print the name of the dll which uses the address space with 
> using the /proc/$PID/maps contents.
> I think this will be really helpfull for other users who have such an error.
> This perhaps in combination with an environment setting in the CYGWIN variable 
> would be really great feature.

The great feature would be if the problem didn't occur at all.  But
that's just idle wishing, I guess.

> Or is there an easy way for me to suspend the thread running into this error?
> So I can start another shell for looking into /proc/$PID/maps.

That's what I meant.  Add a Sleep(100000L) to child_info_fork::abort,
right before the `ExitProcess (EXITCODE_FORK_FAILED)' and build a
Cygwin DLL.  Then, if it happens, the process will linger for 100 seconds,
which is enough time to inspect /proc/$PID/maps using less.


Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple