-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failing Windows tests in the master branch #2890
Comments
Also, note that when I tested #2667, on Windows, the directory for the binaries had name |
These fork related errors are always a possibility whenever you copy cygwin to a different machine, and why officially cygwin doesn't support us doing it. The problem is more likely to trigger as you add more DLLs, so I guess we are just getting unlucky (there are probably other machines it will work on, it's a subtle bug). |
Thanks for explanation @ChrisJefferson and also for telling this morning where For For fork related errors, maybe time to upgrade Cygwin installation we use to build GAP... |
@alex-konovalov On the other hand, why is there a fundamental reason for the 1GB memory limit? I've now hit it a couple of times with more elaborate examples. |
@hulpke yes, I remember that I've asked for it. Still good to have it around. A quick fix would be to move it to benchmarks, a more elaborate would be to split 1GB limit helps to catch memory regressions, and there were cases in the past when its presence allowed to detect some issues. |
But using 1GB is a rather crude way to catch memory regressions. Much better would be to catch the output of TestDirectory, which tells us for each test how much memory it consumed, and then graph that. |
That output has a different meaning though:
or
show how much was in total, which is larger than 1GB, but at any given time the amount of memory used by GAP was smaller than 1GB. |
For reducing the chances of these kinds of fork problems it is good to rebase all executables and DLLs after building. For Sage I use this script (though easily adaptable): https://gitlab.com/sagemath/sage/blob/master/src/bin/sage-rebase.sh This finds all executables and DLLs in Sage and rebases them together. It is run automatically after each build. What "rebase" means in this case is that it ensures each DLL is given its own non-overlapping range in the process's address space. This way, when a process is "forked", the new process will load the same DLLs to the same addresses. Otherwise, they are relocated at runtime by the NT kernel, and there is no way Cygwin can guarantee that they will be loaded again at the same address after a "fork". |
(This is a large part of why porting Sage in particular to 32-bit Cygwin is so difficult: You literally just run out of address spaces for all DLLs in Sage to occupy non-overlapping addresses, even though in typical usage you won't load every DLL). |
Is this issue still relevant? BTW note that on GAP master, I added a year ago code to use |
Fine to close, thanks. |
The Jenkins job to test release candidate for the next major release on a cygwin-free windows machine (only accessible from St Andrews here) last time passed on September 16th 2018, and fails today.
testinstall.g passes without and with default packages. However, teststandard has problems:
If this tess can not be run with our default memory settings, I can move it e.g. to benchmarks to run weekly there in Jenkins.
and
The text was updated successfully, but these errors were encountered: