cygwin build_alias issue

[Bogdan Vacaliuc]

Joel, Everyone,

Here are my results so far (though nothing experimentally conclusive;
grrr.):

Here is a reference to a post that boils down the issue (circa 2002):
http://www.cygwin.com/ml/cygwin/2002-02/msg01068.html

I should have referenced (KB184802 in my earlier post, as it is more
relevant to this hypothesis so far:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;184802

That article suggests that user32.dll or kernel32.dll may fail to initialize
(causing a process exit) for one of two causes.  Cause 2 is the 'out of
desktop heap' problem, which we are considering as a possibility.  The
failure is a that the process exits with an exit code of 128
(ERROR_WAIT_NO_CHILDREN).  There are *three* values to the SharedSection
value in the registry that control the size and allocation unit of each
process regarding this 'desktop heap'.

It also says "Desktop heap is allocated by User32.dll when a process is in
need of user objects. If an application is not dependent on User32.dll, it
will not consume desktop heap."

Using cygcheck on expr.exe, sed.exe and bash.exe shows that expr and sed
only use kernel32.dll, but bash uses both user32.dll and kernel32.dll.

When I first looked at my registry settings, they had the following values
for SharedSection:

SharedSection=1024,3072,512,512

Notice that there were *four* entries, not two or three as the M$ articles
describe.  (the fourth turns out to be limits for terminal services as
mentioned in msg01068), I made the following modifications with the
following observations:

SharedSection=1024,3072,128   // breaks in build every time
SharedSection=1024,3072,1024  // runs with no apps on desktop, breaks in
build with Outlook running
SharedSection=1024,6144,512   // runs intermittently (as before), breaks in
configure as well as build
SharedSection=1024,3072,2048  // configure failed with apps on desktop
(didn't do a complete test)


The overriding item in all of this is that when strace is used, the build
*never* breaks; it always succeeds; even strace --mask=minimal.  What I am
thinking is that the resources in question are in fact 'released'; however,
since CSRSS.EXE actually manages the release, and since new processes get
started before CSRSS.EXE gets a chance to run, the processes spawned by
configure and make 'appear' to run out of these resources and fail in
unpredictable ways.

Perhaps increasing the scheduling priority of CSRSS.EXE?...

More anon...

-bogdan



> -----Original Message-----
> From: Joel Sherrill <joel at OARcorp.com>
> [mailto:joel.sherrill at OARcorp.com] 
> Sent: Wednesday, September 01, 2004 5:36 PM
> To: Steve Holle
> Cc: Ralf Corsepius; Chris Johns; RTEMS Users
> Subject: Re: cygwin build_alias issue
> 
> 
> Steve Holle wrote:
> > <snip>
> > 
> > 
> >> FWIW: Did somebody try the "usual windows resources test", i.e.
> >> reboot, close all apps on the desktop, open a window and run the 
> >> test, open another window and reiterate the test, continue 
> until the
> >> system collapses or the test fails in a different way?
> > 
> > 
> > Steve Strobel has tried rebooting and closing all apps.
> Sometimes it
> > works and sometimes it doesn't.  He has a pretty bare bones windows
> > setup while I have lots of gadgets loaded in the system tray.  I've 
> > built rtems with a number of apps and sometimes other 
> cygwin windows
> > open with no problem.
> 
> I have tried the registry suggestion and increased both
> numbers by 1024. I had one good run, then one with the same 
> failure.  So unless the numbers need to be even larger, that isn't it.
> 
> It does seem rather spurious but I am noticing that the
> failure seems to always be in tools/cpu/generic/configure for 
> me.  Both before and after the registry change.
> 
> --joel
> 
>