Segmentation fault on Windows in Python 3.14.0rc1 when running xdoctest test suite via pytest

Bug report

Bug description:

I'm working to test my packages against 3.14 before it is released, and I'm seeing an error in xdoctest. Specifically, I see a segmentation fault (exit code 139) on Python 3.14.0rc1 on Windows during CI. The test suite passes on all other platforms and Python versions.

I unfortunately don't have a local Windows machine to further debug this, but here's the GitHub Actions job showing the issue:

https://github.com/Erotemic/xdoctest/actions/runs/16727556954/job/47347171954

and here is the parent run where I've done a little initial debugging

https://github.com/Erotemic/xdoctest/actions/runs/16727556954

I've found that this is likely not a problem in xdoctest, as it only occurs when the optional packages are installed. These are listed in details:

Details

optional.txt:

-r colors.txt
-r jupyter.txt

pyflakes >= 2.2.0

# xdev availpkg tomli
tomli>=0.2.0  ; python_version < '3.11.0' and python_version >= '3.6'    # Python 3.6+

jupyter.txt

nbconvert>=6.1.0;  python_version >= '3.7.0' and platform_python_implementation != "PyPy"  # Python 3.7+

# For nbconvert
jinja2>=3.0.0   ; platform_python_implementation != "PyPy"  # Python 3.6+

jupyter_client>=7.0.0 

IPython>=7.23.1 

# Requires psutil? Breaking on pypy windows?
ipykernel>=6.11.0    ; python_version < '4.0'  and python_version >= '3.12' and (platform_system!="Windows" or platform_python_implementation != "PyPy")   # Python 3.12+
ipykernel>=6.0.0     ; python_version < '3.12' and python_version >= '3.7' and (platform_system!="Windows" or platform_python_implementation != "PyPy")   # Python 3.7-3.11

# For IPython-kernel
debugpy>=1.6.0     ;                            python_version >= '3.10'    # Python 3.10+
debugpy>=1.3.0     ; python_version < '3.10' and python_version >= '3.9'    # Python 3.9
debugpy>=1.0.0     ; python_version < '3.9' and python_version >= '3.8'    # Python 3.8

# Needed for 3.10 tests
# Needed for earlier versions of nbconvert
ipython_genutils >= 0.2.0 ;  platform_python_implementation != "PyPy"    # Python 3.10+

# For IPython
jedi>=0.16  

attrs>=19.2.0

# For jupyter-client
jupyter_core >= 4.7.0

and colors.txt:

Pygments >= 2.15.1
colorama >= 0.4.1;platform_system=="Windows"

I will attempt to debug this further as I have time, but I at least wanted to raise the issue in case it helps with the 3.14 release.

CPython versions tested on:

3.14

Operating systems tested on:

Windows

Linked PRs

Could you try enabling faulthandler? That'll display which extensions are active and give a stack trace.

Thanks for testing and trying to debug. Seems like an odd result. Out of 331 tests, 305 passed, 26 skipped, and 0 failed. Then segfault. Only on 3.14.0rc1.

I've added the python -X faulthandler -m pytest option to pytest invocations. I'm also trying to remove optional packages one by one to figure out which one it is, but maybe this will be faster. Need to put this down for now. CI results will be on:

https://github.com/Erotemic/xdoctest/actions/runs/16728338160

It looks like pytest decided not to use faulthandler for some reason. Could you try the PYTHONFAULTHANDLER environment variable instead of -X faulthandler?

The latest CI has the environment variable, but does not seem to have additional information:

https://github.com/Erotemic/xdoctest/actions/runs/16728866008/job/47351734007#step:7:187

Hm, I guess the crash could be inside faulthandler then? Pytest claims to enable faulthandler by default: https://docs.pytest.org/en/7.1.x/how-to/failures.html#fault-handler

Does it happen when you only run a subset of the tests instead of all tests?
Is there a way to run pytest itself in very verbose mode, so that we also see the collections step etc? to see also when pytest is tearing down the whole stuff.
Could you disable output capture as well? maybe it's because output is being captured that not everything is displayed?

I've been removing optional dependencies one at time and found that when removing IPython the error went away. IPython is an optional test dependency so we can verify that xdoctest can run in jupyter notebooks.

Previous dependencies removed before IPython were: debugpy, ipykernel, jupyter_core. Testing to see if it continues to work if only IPython is removed. (It does not).

With just IPython disabled the segfault still exists, and looking at its dependency structure it doesn't seem to pull in other packages in my requirements:

IPython                            IPython: Productive Interactive Computing
├── decorator                      Decorators for Humans
├── ipython-pygments-lexers        Defines a variety of Pygments lexers for highlighting IPython code.
│   └── pygments                   Pygments is a syntax highlighting package written in Python.
├── jedi>=0.16                     An autocompletion tool for Python that can be used for text editors.
│   └── parso<0.9.0,>=0.8.4        A Python Parser
├── matplotlib-inline              Inline Matplotlib backend for Jupyter
│   └── traitlets                  Traitlets Python configuration system
├── pexpect>4.3                    Pexpect allows easy control of interactive console applications.
│   └── ptyprocess>=0.5            Run a subprocess in a pseudo terminal
├── prompt_toolkit<3.1.0,>=3.0.41  Library for building powerful interactive command lines in Python
│   └── wcwidth                    Measures the displayed width of unicode strings in a terminal
├── pygments>=2.4.0                Pygments is a syntax highlighting package written in Python.
├── stack_data                     Extract data from python stack frames and tracebacks for informative displays
│   ├── asttokens>=2.1.0           Annotate AST trees with source code positions
│   ├── executing>=1.2.0           Get the currently executing AST node of a frame, and other information
│   └── pure-eval                  Safely evaluate AST nodes without side effects
└── traitlets>=5.13.0              Traitlets Python configuration system

So it could be an interaction?

Here is the output where output is not captured: https://github.com/Erotemic/xdoctest/actions/runs/16729495078/job/47353849336

pytest was already running with --verbose. I've updated the invocation to:

        python -m pytest --setup-show --log-cli-level=DEBUG -s -vv -p pytester -p no:doctest --xdoctest --cov-config ../pyproject.toml "$MOD_DPATH" ../tests

output will be written: https://github.com/Erotemic/xdoctest/actions/runs/16729811237

It could be stack_data:

├── stack_data Extract data from python stack frames and tracebacks for informative displays

If this one is used, and if somehow, we have some bad constructions on our AST side, maybe there is a code path triggering a segfault somehwere.

By the way, could you try doing simply python -X faulthandler -X dev -m pytest ... directly? it might happen that we actually exited pytest and the segfault occurs outside of that

@Erotemic

@Erotemic if you want to reopen this here, I think we can now say with confidence it is a CPython bug.

This bug has been isolated to only standard library code, and only Windows 3.14 is affected.

The segfault occurs when an unclosed asyncio EventLoop is stored in a ContextVar at process shutdown. The following code reliably segfaults with 3.14.0-rc.2 on Windows (GitHub actions):

import asyncio
from contextvars import ContextVar


context_loop = ContextVar("context_loop", default=None)


def test_crash():
    loop = asyncio.new_event_loop()
    context_loop.set(loop)
    # if loop is unclosed, Windows Python 3.14.0rc2 segfaults at exit
    # if loop is closed, no error
    # loop.close()


if __name__ == "__main__":
    test_crash()
    print("end of script")

Even with faulthandler and devmode enabled, the output is only:

end of script
Segmentation fault      python ./test.py

no errors on 3.14 on linux or mac

@minrk

@minrk Thank you for digging into this and finding the MWE, especially before the 3.14 release!
However, given that it looks like there is a workaround by closing the loop, perhaps this could also be fixed on the xdoctest side? We probably should be closing resources that we open in tests.

I don't have permission to reopen the issue. @ZeroIntensity @terryjreedy Can this get re-opened?

you could close it by running over the current context vars, I suppose?

for item in contextvars.copy_context().values():
    if isinstance(item, asyncio.AbstractEventLoop) and not item.is_closed():
        item.close()

@kumaraditya303

cc @kumaraditya303 as the asyncio maintainer

I have a fix at #138027

This is similar to #126881 where the dtoa state was finalized early, its the same issue here but this time with warnings state and is not related to asyncio.

gh-137384: fix crash when accessing warnings state late in runtime sh…

[3.14] pythongh-137384: fix crash when accessing warnings state late …

[3.14] gh-137384: fix crash when accessing warnings state late in run…

[3.14] pythongh-137384: fix crash when accessing warnings state late …

Navigation Menu

Repository navigation

Segmentation fault on Windows in Python 3.14.0rc1 when running xdoctest test suite via pytest #137384

Bug report

Bug description:

CPython versions tested on:

Operating systems tested on:

Linked PRs

9 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Segmentation fault on Windows in Python 3.14.0rc1 when running xdoctest test suite via pytest #137384

Description

Bug report

Bug description:

CPython versions tested on:

Operating systems tested on:

Linked PRs

Activity

ZeroIntensity commented on Aug 4, 2025

terryjreedy commented on Aug 4, 2025

Erotemic commented on Aug 4, 2025

ZeroIntensity commented on Aug 4, 2025

Erotemic commented on Aug 4, 2025

ZeroIntensity commented on Aug 4, 2025

picnixz commented on Aug 4, 2025

Erotemic commented on Aug 4, 2025

picnixz commented on Aug 4, 2025

picnixz commented on Aug 4, 2025

9 remaining items

minrk commented on Aug 21, 2025

Erotemic commented on Aug 21, 2025

minrk commented on Aug 21, 2025

ZeroIntensity commented on Aug 21, 2025

kumaraditya303 commented on Aug 21, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions