Skip to content

Cannot safely Py_EndInterpreter in 3.14b1 #134144

Description

@b-pass

Crash report

What happened?

Stack trace:

#0  tstate_delete_common.constprop.0 (tstate=tstate@entry=0x555555666ca0, release_gil=0) at ../Python/pystate.c:1854
#1  0x00007ffff78cd341 in zapthreads (interp=0x7ffff74c8010) at ../Python/pystate.c:1915
#2  PyInterpreterState_Delete (interp=0x7ffff74c8010) at ../Python/pystate.c:1016
#3  0x00005555555552ef in main () at repro.c:16

(note the address passed to tstate_delete_common is definitely corrupt, and not the address of any PyThreadState created in this program)

This was triggered by creating a new PyThreeadState for the interpreter, switching to it, deleting an old thread state for the same interpreter, and then calling Py_EndInterpreter (on the new thread state).

repro.c:

#include <Python.h>

int main()
{
        Py_Initialize();

        PyThreadState *orig = NULL;
        PyInterpreterConfig cfg =  _PyInterpreterConfig_INIT;
        Py_NewInterpreterFromConfig(&orig, &cfg);

        PyThreadState *temp = PyThreadState_New(orig->interp);
        PyThreadState_Swap(temp);
        PyThreadState_Clear(orig);
        PyThreadState_Delete(orig);
        Py_EndInterpreter(temp);

        Py_Finalize();
}

Compiled with $ gcc -O1 -ggdb repro.cpp -I/usr/include/python3.14 -lpython3.14

CPython versions tested on:

3.14

Operating systems tested on:

Linux

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

Python 3.14.0b1 (main, May 8 2025, 08:57:13) [GCC 13.3.0]

Linked PRs

Activity

  1. added
    type-crashA hard crash of the interpreter, possibly with a core dump
    on May 17, 2025
  2. ZeroIntensity commented on May 17, 2025

    @ZeroIntensity
    Member

    @ericsnowcurrently This is the zapthreads problem that I was talking about yesterday.

    I'm pretty sure #128640 will fix this.

  3. b-pass commented on May 17, 2025

    @b-pass
    ContributorAuthor

    I updated the example code to a complete compilable description, this crashes for me. Using deadsnakes repo on ubuntu 24.04, which is 3.14.b1.

  4. ZeroIntensity commented on May 17, 2025

    @ZeroIntensity
    Member

    Huh, that repro looks wrong. PyThreadState_Delete cannot be called with a thread state that is attached.

  5. b-pass commented on May 17, 2025

    @b-pass
    ContributorAuthor

    Huh, that repro looks wrong. PyThreadState_Delete cannot be called with a thread state that is attached.

    Does the PyThreadState_Swap not detach it?

  6. ZeroIntensity commented on May 17, 2025

    @ZeroIntensity
    Member

    Oh wait, I see that you delete orig, not temp.

  7. b-pass commented on May 18, 2025

    @b-pass
    ContributorAuthor

    If it matters, the reason I am doing it this way is that in 3.12 you can't actually delete (via PyThreadState_Delete) the first PyThreadState of the interpreter ... it looks to me like it never gets zero'd out (because it is the one that has storage inside the interpreterstate) so it causes an abort when it is subsequently reallocated. :( So you have to leave that one allocated. This is fixed in 3.13+

  8. added a commit that references this issue on May 18, 2025
  9. added a commit that references this issue on May 18, 2025
  10. added a commit that references this issue on May 18, 2025
  11. added a commit that references this issue on Jul 12, 2025
  12. added a commit that references this issue on Aug 4, 2025
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

    3.14bugs and security fixes3.15bugs and security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)topic-subinterpreterstype-crashA hard crash of the interpreter, possibly with a core dump

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions