| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bump the version of `Win32` to `2.5.0.0` which is a major update and includes
fixes for wrong alignments and wrong 64-bit types. Strangely enough this also
seems to resolve #12713, where `T10858` was failing due to too-low allocations.
The underlying type aliases have changed, so there is a potential
for user programs not to compile anymore, but the types were incorrect.
This also requires a bump in the `directory`, `Cabal`, and `process`
submodules.
Original author: Tamar Christina <tamar@zhox.com>
Test Plan: ./validate
Reviewers: bgamari, RyanGlScott, austin
Subscribers: hvr, RyanGlScott, thomie, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D2938
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
we spawn the child processes with handle inheritance on. So they inherit the std handles.
The problem is that the job handle gets inherited too.
So the `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE` doesn't get used since there are
open handles to the job in the children.
We then terminate the top level process which is `sh` but leaves the children around.
This explicitly disallows the inheritance of the job and events handle.
Test Plan: ./validate
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D2895
GHC Trac Issues: #13004
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Timeout has been broken by my previous patch.
The timeout event was not being processed correctly,
as such hanging processes would not be killed as they should
have been.
This corrects it.
Test Plan:
./validate
~/ghc/testsuite/timeout/install-inplace/bin/timeout.exe 10 "sleep 10000s"
Reviewers: austin, RyanGlScott, bgamari
Reviewed By: bgamari
Subscribers: thomie, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D2880
GHC Trac Issues: #13004
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix issues preventing x86 GHC to build on Windows and
fix segfault in the testsuite.
Test Plan: ./validate
Reviewers: austin, erikd, simonmar, bgamari
Reviewed By: bgamari
Subscribers: #ghc_windows_task_force, thomie
Differential Revision: https://phabricator.haskell.org/D2789
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a land far far away, a project called Cygwin was born.
Cygwin used newlib as it's standard C library implementation.
But Cygwin wanted to emulate POSIX systems as closely as possible.
So it implemented `execv` using the Windows function `spawnve`.
Specifically
```
spawnve (_P_OVERLAY, path, argv, cur_environ ())
```
`_P_OVERLAY` is crucial, as it makes the function behave *sort of*
like execv on linux. the child process replaces the original process.
With one major difference because of the difference in process models
on Windows: the original process signals the caller that it's done.
this is why the file is still locked. because it's still running,
control was returned because the parent process was destroyed,
but the child is still running.
I think it's just pure dumb luck, that the older runtimes are slow
enough to give the process time to terminate before we tried deleting
the file. Which explains why you do have sporadic failures even on
older runtimes like 2.5.0, of a test or two (like T7307).
So this patch fixes a couple of things. I leverage the existing
`timeout.exe` to implement a workaround for this issue.
a) The old timeout used to start the process then assign it to the job.
This is slightly faulty since child processes are only assigned to a
job is their parent were assigned at the time they started. So this
was a race condition. I now create the process suspended, assign it
to the job and then resume it. Which means all child processes are
not running under the same job.
b) First things, Is to prevent dangling child processes. I mark the job
with `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE` so when the last process in
the job is done, it insures all processes under the job are killed.
c) Secondly, I change the way we wait for results. Instead of waiting
for the parent process to terminate, I wait for the job itself to
terminate.
There's a slight subtlety there, we can't wait on the job itself.
Instead we have to create an I/O Completion port and wait for signals
on it. See
https://blogs.msdn.microsoft.com/oldnewthing/20130405-00/?p=4743
This fixes the issues on all runtimes for me and makes T7307 pass
consistenly.
The threading was also simplified by hiding all the locking in a single
semaphore and a completion class. Futhermore some additional error
reporting was added.
For encoding the testsuite now no longer passes a file handle to the
subprocess since on windows, sh.exe seems to acquire a lock on the file
that is not released in a timely fashion.
I suspect this because cygwin seems to emulate console handles by
creating file handles and using those for std handles. So when we give
it an existing file handle it just locks the file. I what's happening is
that it's not releasing the handle until all shared cygwin processes are
dead. Which explains why it worked in single threaded mode.
So now instead we pass a pipe and do not interpret the resulting data.
Any bytes written to stdin or read out of stdout/stderr are done so in
binary mode and we do not interpret the data. The reason for this is
that we have encoding tests in GHC which pass invalid utf-8. If we try
to handle the data as text then python will throw an exception instead
of a test comparison failing.
Also I have fixed the ability to override `PYTHON` when calling `make
tests`. This now works the same as with `.\validate`.
Finally, after cleaning up the locks I was able to make the abort
behavior work correctly as I believe it was intended: when you press
Ctrl+C and send an interrupt signal, the testsuite finishes the active
tests and then gracefully exits showing you a report of the progress it
did make. So using Ctrl+C will not just *die* as it did before.
These changes lift the restriction on which python version you use
(msys/mingw) or which runtime or python 3 or python 2. All combinations
should now be supported.
Test Plan:
PATH=/usr/local/bin:/mingw64/bin:$APPDATA/cabal/bin:$PATH &&
PYTHON=/usr/bin/python THREADS=9 make test
THREADS=9 make test
PATH=/usr/local/bin:/mingw64/bin:$APPDATA/cabal/bin:$PATH &&
PYTHON=/usr/bin/python ./validate --quiet --testsuite-only
Reviewers: erikd, RyanGlScott, bgamari, austin
Subscribers: jrtc27, mpickering, thomie, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D2684
GHC Trac Issues: #12725, #12554, #12661, #12004
|
| | |
|
| | |
|
| |
|
