Use python 3.14 environment in GitHub workflows by antonwolfy · Pull Request #2922 · IntelPython/dpnp

antonwolfy · 2026-05-18T09:42:39Z

This PR updates the remaining GitHub workflows and conda environments to run under python 3.14, and bumps coveralls to 4.1.0 (which supports 3.14).

Version bumps (3.13/3.12 → 3.14)

check-onemath.yaml — oneMath interface tests
conda-package.yml — array API conformance tests (python-ver)
environments/building_docs.yml — docs build
environments/upload_cleanup_conda_pkg.yml — conda package upload/cleanup
environments/coverage.yml — coverage job (was pinned to 3.12)

Coverage job fixes for python 3.14

Bumping the coverage environment from 3.12 to 3.14 surfaced two failures unrelated to dpnp's runtime code — both stem from how coverage instrumentation interacts with 3.14's sys.monitoring:

1. Build failure — undeclared identifier '__Pyx_MonitoringEventTypes_CyGen_count'

Coverage builds compile every extension with CYTHON_TRACE=1 (DPNP_GENERATE_COVERAGE=ON), but Cython line tracing also needs the matching # cython: linetrace=True directive at cythonize time. Three .pyx files were missing it (_slicing.pyx, _stride_utils.pyx, _types.pyx): without the directive, Cython references __Pyx_MonitoringEventTypes_CyGen_count (from the shared generator/coroutine struct) but never defines it. On python ≤3.12 the guarding CYTHON_USE_SYS_MONITORING macro is 0, so the code was unreachable — which is why the previous 3.12 pin hid this; on 3.13+ it becomes reachable and fails to compile. Added the directive to the three files. As a side effect, these files were previously producing no line-coverage data and are now measured.

2. Test failures — test_dlpack.py::TestDLPack::test_invaid_stream[scalar|dictionary|device]

coverage.py 7.9+ makes the sys.monitoring core (sysmon) the default on python 3.14. That core (a) does not support plugins such as the Cython.Coverage plugin used here, and (b) corrupts the pending exception when a C/Cython function raises — turning dpctl's correct TypeError from usm_ndarray.__dlpack__ into a SystemError, so assert_raises(TypeError, ...) fails. Pinned the measurement core back to ctrace via core = "ctrace" in [tool.coverage.run] (pyproject.toml). ctrace supports both the Cython plugin and branch coverage, so no coverage data is lost.

Have you provided a meaningful PR description?
Have you added a test, reproducer or referred to an issue with a reproducer?
Have you tested your changes locally for CPU and GPU devices?
Have you made sure that new changes do not introduce compiler warnings?
Have you checked performance impact of proposed changes?
Have you added documentation for your changes, if necessary?
Have you added your changes to the changelog?

github-actions · 2026-05-18T10:43:31Z

View rendered docs @ https://intelpython.github.io/dpnp/index.html

github-actions · 2026-05-18T11:25:51Z

Array API standard conformance tests for dpnp=0.21.0dev3=py314h509198e_13 ran successfully.
Passed: 1373
Failed: 2
Skipped: 5

vlad-perevezentsev

LGTM
Thank you @antonwolfy

…ith `CYTHON_TRACE=1`

vlad-perevezentsev

LGTM
Thank you @antonwolfy

This PR updates the remaining GitHub workflows and conda environments to run under python 3.14, and bumps coveralls to 4.1.0 (which supports 3.14). ### Version bumps (3.13/3.12 → 3.14) - `check-onemath.yaml` — oneMath interface tests - `conda-package.yml` — array API conformance tests (`python-ver`) - `environments/building_docs.yml` — docs build - `environments/upload_cleanup_conda_pkg.yml` — conda package upload/cleanup - `environments/coverage.yml` — coverage job (was pinned to `3.12`) ### Coverage job fixes for python 3.14 Bumping the coverage environment from 3.12 to 3.14 surfaced two failures unrelated to dpnp's runtime code — both stem from how coverage instrumentation interacts with 3.14's `sys.monitoring`: **1. Build failure — `undeclared identifier '__Pyx_MonitoringEventTypes_CyGen_count'`** Coverage builds compile every extension with `CYTHON_TRACE=1` (`DPNP_GENERATE_COVERAGE=ON`), but Cython line tracing also needs the matching `# cython: linetrace=True` directive at cythonize time. Three `.pyx` files were missing it (`_slicing.pyx`, `_stride_utils.pyx`, `_types.pyx`): without the directive, Cython references `__Pyx_MonitoringEventTypes_CyGen_count` (from the shared generator/coroutine struct) but never defines it. On python ≤3.12 the guarding `CYTHON_USE_SYS_MONITORING` macro is `0`, so the code was unreachable — which is why the previous `3.12` pin hid this; on 3.13+ it becomes reachable and fails to compile. Added the directive to the three files. As a side effect, these files were previously producing no line-coverage data and are now measured. **2. Test failures — `test_dlpack.py::TestDLPack::test_invaid_stream[scalar|dictionary|device]`** coverage.py 7.9+ makes the `sys.monitoring` core (`sysmon`) the default on python 3.14. That core (a) does not support plugins such as the `Cython.Coverage` plugin used here, and (b) corrupts the pending exception when a C/Cython function raises — turning dpctl's correct `TypeError` from `usm_ndarray.__dlpack__` into a `SystemError`, so `assert_raises(TypeError, ...)` fails. Pinned the measurement core back to `ctrace` via `core = "ctrace"` in `[tool.coverage.run]` (`pyproject.toml`). `ctrace` supports both the Cython plugin and branch coverage, so no coverage data is lost. 3a91802

The GutHub coverage workflow started hanging right after the coverage environment was bumped from Python 3.12 to 3.14 (#2922). This PR fixes the hang by compiling the coverage build with `CYTHON_USE_SYS_MONITORING=0`, forcing Cython to use its legacy `settrace`-based line tracing instead of the `sys.monitoring` path that becomes the default on Python 3.13+. ### Root cause Coverage builds compile every Cython extension with line tracing (`CYTHON_TRACE=1 CYTHON_TRACE_NOGIL=1` + `# cython: linetrace=True`). On Python 3.13+, Cython gates its tracing implementation on `CYTHON_USE_SYS_MONITORING` (`PY_VERSION_HEX >= 0x030d00B1`) and emits `sys.monitoring` hooks directly into the compiled `.so`. Those hooks fire exception/unwind events (`PyMonitoring_FireRaiseEvent`, `PyMonitoring_FirePyUnwindEvent`, ...) **without preserving the in-flight exception** — unlike the legacy path (`__Pyx_call_line_trace_func`), which brackets the trace call with `PyErr_Fetch`/`PyErr_Restore`. When an exception propagates out of an instrumented `.pyx` frame, this corrupts the interpreter's error state: the correct exception is turned into a `SystemError` ("returned a result with an exception set"), and the process then hangs. This is an upstream Cython bug: cython/cython#6658 (open, same failure mode — Cython + coverage + Python 3.13 `sys.monitoring` → `SystemError` and hang). The first test to trigger this is `test_dlpack.py::TestDLPack::test_invaid_stream`, which does `assert_raises(TypeError, x.__dlpack__, stream=<invalid>)`. The `TypeError` is raised in the instrumented `dpnp/tensor/_usmarray.pyx` (`_validate_and_use_stream`) and unwinds out through `usm_ndarray.__dlpack__`, hitting the corruption. #### Why not just rely on `core = "ctrace"`? PR #2922 added `core = "ctrace"` in `pyproject.toml` to keep **coverage.py** off the `sysmon` measurement core (needed for the `Cython.Coverage` plugin). That is still required and unchanged. But it only controls coverage.py's own tracer — the corruption here comes from **Cython's compiled-in** `sys.monitoring` instrumentation, which is gated purely on the Python version and independent of coverage.py's core choice. `CYTHON_USE_SYS_MONITORING=0` addresses that side; the two settings are complementary.

The GutHub coverage workflow started hanging right after the coverage environment was bumped from Python 3.12 to 3.14 (#2922). This PR fixes the hang by compiling the coverage build with `CYTHON_USE_SYS_MONITORING=0`, forcing Cython to use its legacy `settrace`-based line tracing instead of the `sys.monitoring` path that becomes the default on Python 3.13+. ### Root cause Coverage builds compile every Cython extension with line tracing (`CYTHON_TRACE=1 CYTHON_TRACE_NOGIL=1` + `# cython: linetrace=True`). On Python 3.13+, Cython gates its tracing implementation on `CYTHON_USE_SYS_MONITORING` (`PY_VERSION_HEX >= 0x030d00B1`) and emits `sys.monitoring` hooks directly into the compiled `.so`. Those hooks fire exception/unwind events (`PyMonitoring_FireRaiseEvent`, `PyMonitoring_FirePyUnwindEvent`, ...) **without preserving the in-flight exception** — unlike the legacy path (`__Pyx_call_line_trace_func`), which brackets the trace call with `PyErr_Fetch`/`PyErr_Restore`. When an exception propagates out of an instrumented `.pyx` frame, this corrupts the interpreter's error state: the correct exception is turned into a `SystemError` ("returned a result with an exception set"), and the process then hangs. This is an upstream Cython bug: cython/cython#6658 (open, same failure mode — Cython + coverage + Python 3.13 `sys.monitoring` → `SystemError` and hang). The first test to trigger this is `test_dlpack.py::TestDLPack::test_invaid_stream`, which does `assert_raises(TypeError, x.__dlpack__, stream=<invalid>)`. The `TypeError` is raised in the instrumented `dpnp/tensor/_usmarray.pyx` (`_validate_and_use_stream`) and unwinds out through `usm_ndarray.__dlpack__`, hitting the corruption. #### Why not just rely on `core = "ctrace"`? PR #2922 added `core = "ctrace"` in `pyproject.toml` to keep **coverage.py** off the `sysmon` measurement core (needed for the `Cython.Coverage` plugin). That is still required and unchanged. But it only controls coverage.py's own tracer — the corruption here comes from **Cython's compiled-in** `sys.monitoring` instrumentation, which is gated purely on the Python version and independent of coverage.py's core choice. `CYTHON_USE_SYS_MONITORING=0` addresses that side; the two settings are complementary. 987f299

antonwolfy added this to the 0.21.0 release milestone May 18, 2026

antonwolfy self-assigned this May 18, 2026

antonwolfy changed the title ~~Use python 3.14 environment in GitHub workflows where possible~~ Use python 3.14 environment in GitHub workflows May 18, 2026

antonwolfy marked this pull request as ready for review May 18, 2026 13:18

antonwolfy requested review from ndgrigorian and vlad-perevezentsev as code owners May 18, 2026 13:19

vlad-perevezentsev approved these changes May 19, 2026

View reviewed changes

antonwolfy added 5 commits July 9, 2026 13:32

Run tests for oneMath interface with python 3.14

4e1b098

Run Python array API conformance tests with python 3.14

ca34530

Build docs within python 3.14 env

7a96961

Upload conda pacakges within python 3.14 env

e9be29b

Collect tests coverage within python 3.14 env

cded1c6

antonwolfy force-pushed the use-py3.14-in-gh-workflows branch from 60bde39 to cded1c6 Compare July 9, 2026 11:32

antonwolfy added 2 commits July 9, 2026 14:46

Add missing # cython: linetrace=True since required when building w…

5e32419

…ith `CYTHON_TRACE=1`

Pin to use legacy coverage.core='ctrace'

a357917

antonwolfy requested a review from vlad-perevezentsev July 9, 2026 17:10

vlad-perevezentsev approved these changes Jul 16, 2026

View reviewed changes

Merge branch 'master' into use-py3.14-in-gh-workflows

be6dfd7

antonwolfy merged commit 3a91802 into master Jul 20, 2026
75 of 83 checks passed

antonwolfy deleted the use-py3.14-in-gh-workflows branch July 20, 2026 11:19

antonwolfy mentioned this pull request Jul 21, 2026

Fix hanging coverage workflow #3004

Merged

7 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Use python 3.14 environment in GitHub workflows#2922

Use python 3.14 environment in GitHub workflows#2922
antonwolfy merged 8 commits into
masterfrom
use-py3.14-in-gh-workflows

antonwolfy commented May 18, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented May 18, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented May 18, 2026 •

edited

Loading

Uh oh!

vlad-perevezentsev left a comment

Uh oh!

vlad-perevezentsev left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

antonwolfy commented May 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Version bumps (3.13/3.12 → 3.14)

Coverage job fixes for python 3.14

Uh oh!

github-actions Bot commented May 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented May 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vlad-perevezentsev left a comment

Choose a reason for hiding this comment

Uh oh!

vlad-perevezentsev left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

antonwolfy commented May 18, 2026 •

edited

Loading

github-actions Bot commented May 18, 2026 •

edited

Loading

github-actions Bot commented May 18, 2026 •

edited

Loading