Strange errors running gcc tests on Cygwin

Daniel Santos
Sun Mar 12 04:04:00 GMT 2017

Thanks for the help Brian.

On 03/09/2017 05:51 PM, Brian Inglis wrote:
> Windows DLLs updated or added could increase in size and overlap
> Cygwin's assumed address space allocated by rebase.
> Mingw has no problem as native Windows programs, but Cygwin emulates
> how Unix uses shared libraries [handwaving simplification], so
> Cygwin 32 has problems with limited 32 bit space available to programs.

Well, I tried it anyway and there was no change.

> Bump to 310 as optimal max - see man cygserver.
> Should be started before sshd and any other Cygwin processes
> and should be configured to start sshd.

Ah! Well I didn't have sshd set as depending upon cygserver (I do not).  
There was no change in the outcome however.

> <Win-Break> or Control Panel/System/Advanced system settings/
> /Advanced tab/Performance [Settings] button/Advanced tab/
> /Virtual memory [Change] button/Virtual Memory dialogue box:
> [ ] Automatically manage...	uncheck
> ...
> (@) Custom size:		select
> Initial size (MB): [ 8192 ]	double RAM
> Maximum size (MB): [ 16384 ]	just in case
> ( ) System managed size		deselect
> ( ) No paging file		deselect
> then select *[Set]* button and reboot if prompted.
> You may have to allocate more VM disk space if insufficent.

Ok, that's done.

> Start Task Manager/Performance tab/Open Resource Monitor link at bottom/
> /Resource Monitor/Memory tab/Physical Memory pane at bottom/
> Free should never go much below 100MB and trouble is almost certain
> if you ever hit single digits even for an instant.

Well, I'm certainly not watching task manager for 11-12 hours straight. 
:) However, I seem to continuously have at least 2GiB free.

> Ensure that all Cygwin dlls including anything you build are included
> in every rebase, and do an incremental rebase after every build.

Hmm, so how do I do this?  Is this something that the gcc build *should* 
be doing?  If this is really required, I will open a gcc bug report for it.


I've done a lot of work at the system and kernel level and this SCREAMS 
race condition to me -- and not necessarily in Cygwin.  In fact, I would 
venture to guess that we're dealing with more than one serious issue and 
I don't know where they are.  It is not at all uncommon for a very 
common piece of software to have a race condition that is never exposed 
on one OS but is exposed on another -- this is very common when running 
programs on Wine, for instance.

At current, I seem to be able to run the tests single threaded (one at a 
time) and get no broken pipes and only 8 time-outs.  I suppose that is 
close enough, but I have 8 total tests that need to be run (cygwin-64, 
cygwin-32, mingw64 and mingw64 -- both with and without my patches).  So 
this may simply take me many, many days to complete.  I'm experimenting 
with running under wine, but bash.exe is crashing right now (although my 
Wine had the staging patches, so building w/o them :)



Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list