TST: Windows job has 4 failures

Not sure why it started cropping up. Needs investigation. I see this on main and also v6.1.x backport branch.

Example log: https://github.com/astropy/astropy/actions/runs/10065517821/job/27824832713

FAILED astropy\io\fits\tests\test_hdulist.py::TestHDUListFunctions::test_update_resized_header[] - UserWarning: Memory map object was closed but appears to still be referenced. Further access will result in undefined behavior (possibly including segmentation faults).
FAILED astropy\io\fits\tests\test_hdulist.py::TestHDUListFunctions::test_update_resized_header[home_is_data] - UserWarning: Memory map object was closed but appears to still be referenced. Further access will result in undefined behavior (possibly including segmentation faults).
FAILED astropy\io\fits\tests\test_hdulist.py::TestHDUListFunctions::test_update_resized_header[home_is_data, pathlib] - UserWarning: Memory map object was closed but appears to still be referenced. Further access will result in undefined behavior (possibly including segmentation faults).
FAILED astropy\io\fits\tests\test_image.py::TestImageFunctions::test_io_manipulation - UserWarning: Memory map object was closed but appears to still be referenced. Further access will result in undefined behavior (possibly including segmentation faults).

I want to blame Crowdstrike but probably not caused by them.

Here's one of the last runs to succeed:
https://github.com/astropy/astropy/actions/runs/10055868741/job/27793494345
And one of the first to fail:
https://github.com/astropy/astropy/actions/runs/10061840724/job/27812887553

And a diff of their respective resolved envs:

10c10
< astropy @ file:///D:/a/astropy/astropy/.tox/.tmp/package/1/astropy-7.0.0.dev452%2Bg81da00d96a.tar.gz#sha256=bb3cbe1c5c554c4eed798f1857f19fe44dacaa1d97c3f61b76041cd6b5e98e2c
---
> astropy @ file:///D:/a/astropy/astropy/.tox/.tmp/package/1/astropy-7.0.0.dev452%2Bgaf5306eead.tar.gz#sha256=2231c63253736e7cf77fa68cb52d93481c764845b590d7fe23c9f78b158fd0d9
42c42
< importlib_metadata==8.0.0
---
> importlib_metadata==8.1.0
61c61
< numpy==1.26.4
---
> numpy==2.0.1

The warning that we're seeing was introduced in #16581+#16608 but I assumed (at the time) that we were already testing the combo (Windows+numpy2). Evidently we were not. What I don't understand off-hand is why this changed so suddenly.
I'll see if I can adjust this.

why this changed so suddenly

astropy/.github/workflows/ci_workflows.yml

Lines 84 to 86 in d8e98c2

    
                   - name: Python 3.11 with all optional dependencies (Windows) 
        
                     windows: py311-test-alldeps 
        
                     posargs: --durations=50

Maybe one of the "optional dependencies" finally unpinned numpy<2. That is the only logical reason I can think of. We did patch a conda-forge recipe for Windows yesterday but that should not affect CI.

Not sure that makes sense since the only other dependency that changed in the interval (importlib_metadata) has nothing to do with numpy. That said I don't fancy figuring out what happened 🤷‍♂️

Could very well be something on server side but yes, let's move on. 😅

Navigation Menu

Repository navigation

TST: Windows job has 4 failures #16765

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	- name: Python 3.11 with all optional dependencies (Windows)
	windows: py311-test-alldeps
	posargs: --durations=50

TST: Windows job has 4 failures #16765

Description

Activity

neutrinoceros commented on Jul 24, 2024

pllim commented on Jul 24, 2024

neutrinoceros commented on Jul 24, 2024

pllim commented on Jul 24, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions