Visitar URL original
`exec(<string>, closure=<non-None>)` failed assertion · Issue #130070 · python/cpython · GitHub
Skip to content

exec(<string>, closure=<non-None>) failed assertion #130070

Closed

Description

@johnslavik

Crash report

What happened?

Minimal repro:

print("Reproducing!")
exec("", closure=object())

Fails with

Reproducing!
python: Python/ast.c:1047: _PyAST_Validate: Assertion `!PyErr_Occurred()' failed.
Aborted (core dumped)

Note the error occurs not because the passed closure= is incorrect (it should be a tuple of cell objects), but because closure= is not allowed when string is the source.

The reason for that to happen is a missing goto error jump:

cpython/Python/bltinmodule.c

Lines 1175 to 1178 in 2a0256f

if (closure != NULL) {
PyErr_SetString(PyExc_TypeError,
"closure can only be used when source is a code object");
}

causing the rest of the code to execute and reach _PyAST_Validate.

In the PR, I included the missing test case.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Output from running 'python -VV' on the command line:

Python 3.14.0a5+ (heads/main-dirty:f9a7d41bacb, Feb 13 2025, 04:52:15) [GCC 11.4.0]

Linked PRs

Activity

  1. added
    type-crashA hard crash of the interpreter, possibly with a core dump
    on Feb 13, 2025
  2. StanFromIreland commented on Feb 13, 2025

    @StanFromIreland
    Member

    Unable to reproduce in 3.13 or main branch build with the supplied code:

    Reproducing!
    Traceback (most recent call last):
      File "<python-input-0>", line 2, in <module>
        exec("", closure=object())
        ~~~~^^^^^^^^^^^^^^^^^^^^^^
    TypeError: closure can only be used when source is a code object
    
  3. johnslavik commented on Feb 13, 2025

    @johnslavik
    MemberAuthor

    Oh! This isn't a segfault. It says "aborted".

  4. changed the title [-]`exec(<string>, closure=<non-None>)` segfaults[/-] [+]`exec(<string>, closure=<non-None>)` failed assertion[/+] on Feb 13, 2025
  5. johnslavik commented on Feb 13, 2025

    @johnslavik
    MemberAuthor

    @tomasr8 Should the label be changed to type-bug? It's not a hard crash, just a subtle bug, even though a core dump is produced.

  6. encukou commented on Feb 13, 2025

    @encukou
    Member

    It crashes in debug builds.

  7. added a commit that references this issue on Apr 17, 2025
  8. added 3 commits that reference this issue on Apr 17, 2025
  9. added a commit that references this issue on Apr 17, 2025
  10. Eclips4 commented on Apr 17, 2025

    @Eclips4
    Member

    Thank you Bartosz!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    interpreter-core(Objects, Python, Grammar, and Parser dirs)type-crashA hard crash of the interpreter, possibly with a core dump

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions